Эффективная структура таблиц базы данных

Рассмотреть Microsoft SQL Server 2008

Мне нужно создать таблицу, которую можно создать двумя разными способами, как показано ниже.

Structure Columnwise
StudentId number, Name Varchar, Age number, Subject varchar
eg.(1,'Dharmesh',23,'Science')
   (2,'David',21,'Maths')


Structure Rowwise
AttributeName varchar,AttributeValue varchar
eg.('StudentId','1'),('Name','Dharmesh'),('Age','23'),('Subject','Science')
   ('StudentId','2'),('Name','David'),('Age','21'),('Subject','Maths')

в первом случае записей будет меньше, а во втором - в 4 раза больше, но 2 столбца уменьшатся.

Итак, какой подход лучше с точки зрения производительности, дискового пространства и повторного использования данных??


sql-server sql-server-2008 sql-server-2008r2-express
person Dharmesh    schedule 17.02.2012    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Ваш второй подход широко известен как EAV дизайн - Сущность-Атрибут-Значение.

ИМХО, 1-й подход полностью. Это позволяет вам правильно вводить столбцы, обеспечивая наиболее эффективное хранение данных, и значительно упрощает и повышает эффективность запросов.

По моему опыту, подход EAV обычно причиняет мир боли. Вот один пример предыдущего вопроса по этому поводу с хорошими ссылками на передовой опыт. Если вы выполните поиск, вы найдете больше - стоит просеять.

Распространенная причина, по которой люди идут по пути EAV, заключается в моделировании гибкой схемы, что относительно сложно сделать эффективно в РСУБД. Другие подходы включают хранение данных в полях XML. Это одна из причин, по которой базы данных NOSQL (нереляционные) могут оказаться очень удобными из-за их бессхемной природы (например, MongoDB).

person AdaTheDev    schedule 17.02.2012

arrow_upward
4
arrow_downward

Первый будет иметь лучшую производительность, дисковое хранилище и извлечение данных будет лучше.

  1. Наличие имен атрибутов в виде varchars сделает невозможным изменение имен, типов данных или применение какой-либо проверки.
  2. Будет невозможно проиндексировать нужные поисковые действия
  3. Сохранение целых чисел в виде varchars займет больше места
  4. Упорядочение, добавление или суммирование целых чисел будет головной болью и будет иметь плохую производительность.
  5. Язык программирования, использующий эту базу данных, не будет иметь возможности иметь строго типизированные данные.

Есть еще много причин для использования первого подхода.

person Schiavini    schedule 17.02.2012