Структура данных и вопросы проектирования систем

Связанные списки, деревья и стеки — это инструменты для работы с данными в программе. Таблицы базы данных, схемы таблиц и отношения — это инструменты для хранения данных. «Система» использует оба из них, но для разных целей, но они работают вместе.

«Разработайте систему для такого-то и такого-то». Это вопрос более высокого уровня, поэтому я бы сначала начал с обсуждения таблиц базы данных, а затем, в зависимости от того, насколько они детализированы, перешел к специфике программы.

«Какую структуру данных вы бы использовали для того-то и того-то?» Это звучит как вопрос о разработке алгоритма, поэтому здесь вас, вероятно, спрашивают о деревьях и стеках.

Надеюсь, это поможет: р

На собеседованиях вопросы, предназначенные для проверки вашего знакомства со структурами данных (и часто с алгоритмической сложностью), НЕ касаются реляционных баз данных. Вопросы о проектировании системы вполне могут касаться части проектирования базы данных.

Все структуры данных, которые вы упомянули, важны. Одной из наиболее явно отсутствующих и очень важной является хеш-таблицы (или неупорядоченные карты, а также основа для структуры данных во многих языках сценариев, таких как dicts в python и объекты/карты в javascript). Вам также следует прочитать об btrees, которые обычно используются для реализации реляционных баз данных (и имеют свойства, такие как бинарные деревья поиска, но лучше подходят для хранения на диске).

На стажировке это не нормально.

Я ожидаю, что вы знакомы с фундаментальными структурами данных, но не ожидаю, что вы станете экспертом в какой-либо из них. (Во всяком случае, экспертом я бы его не назвал.) Меня больше интересует, как вы отвечаете на вопросы, которые явно выходят за рамки ваших нынешних знаний. Если бы я спросил вас о теоретических преимуществах дерева Ван-Эмде-Боаса, «я не знаю», вероятно, был бы правильным ответом. (Лучше, чем пытаться меня блефовать.)

Но с практической точки зрения вы можете с пользой применить принципы реляционного проектирования ко многим проблемам, которые явно не являются реляционными. Большинство приложений Lotus Notes выиграли бы от прочной реляционной архитектуры. Несмотря на то, что вы не можете декларативно реализовать ограничения в Notes, вы все равно должны их каким-то образом учитывать — отчеты об исключениях, обход документа периода и т. д.

И, IIRC, первый расширенный пример в Large Scale C++ Design был в такой же степени проблемой реляционного проектирования, как и проблемой проектирования C++ или OO. (Эта статья была опубликована в 1996 году. Неужели я такой старый? Да, наверное.)