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

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

0 голосов
/ 17 февраля 2012

Рассмотрим 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 столбца уменьшены.

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

Ответы [ 2 ]

4 голосов
/ 17 февраля 2012

Ваш второй подход обычно известен как EAV design - Entity-Attribute-Value.

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

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

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

4 голосов
/ 17 февраля 2012

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

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

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

...