Дизайн и производительность БД

Question

Я сейчас нахожусь в процессе проектирования базы данных. У нас есть существующая система, которая была разработана не очень хорошо, и мы решаем все мелкие проблемы, которые хорошо видны, например, varchar для флага true/false вместо bit.

Что я хочу знать, как вы узнаете, что у вас есть сладкий дизайн базы данных? Или это миф? Я имею в виду, что структура может выглядеть потрясающе на бумаге, но когда некоторые данные будут там, как она будет работать.

Являются ли таблицы, в которых хранятся "поисковые" значения, быстрее, чем хранение полного описательного текста? например,

Таблица ошибок

Id    ErrorId    DateCreated
1     1          09/12/2011
2     5          10/12/2011

Таблица описания ошибок

Id    Description
1     Warning - failed to validate
2     Failed to locate file

В этом случае создание view будет более выгодным, чем написание SQL, включая необходимое объединение?

Извините, если я разместил этот вопрос не в том месте.

Answer 1

Являются ли таблицы, в которых хранятся "поисковые" значения, быстрее, чем хранение полного описательного текста?

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

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

Но «быстрее» не обязательно означает «быстро». И «медленнее» может быть достаточно быстро.