SQL 2008: использование отдельных таблиц для каждого типа данных для возврата одной строки - PullRequest
Новая
       20

SQL 2008: использование отдельных таблиц для каждого типа данных для возврата одной строки

0 голосов
/ 13 апреля 2010

Я подумал, что на этот раз я буду гибким и позволю пользователям решать, какую контактную информацию вы хотите сохранить в своей базе данных. В теории это выглядело бы как одна строка, содержащая, например; имя, адрес, почтовый индекс, категория X, Listitems A.

* ** 1003 тысяча два * Пример
FieldType таблица, определяющая типы данных, доступные пользователю: 
FieldTypeID, FieldTypeName, TableName
1,"Integer","tblContactInt"
2,"String50","tblContactStr50"
...

Пользователь может определить свои поля в таблице FieldDefinition : 

FieldDefinitionID, FieldTypeID, FieldDefinitionName
11,2,"Name"
12,2,"Address"
13,1,"Age"

Наконец, мы сохраняем фактические контактные данные в отдельных таблицах в зависимости от их типа данных. Основная таблица, содержит только ContactID

tblContact 

ContactID
21
22

tblContactStr50 : 

ContactStr50ID,ContactID,FieldDefinitionID,ContactStr50Value
31,21,11,"Person A"
32,21,12,"Address of person A"
33,22,11,"Person B"

tblContactInt 

ContactIntID,ContactID,FieldDefinitionID,ContactIntValue
41,22,13,27

Вопрос: Можно ли вернуть содержимое этих таблиц в две строки, например: 

ContactID,Name,Address,Age
21,"Person A","Address of person A",NULL
22,"Person B",NULL,27

Я изучил использование таблиц COALESCE и Temp, задаваясь вопросом, возможно ли это вообще. Даже если это так: возможно, я только добавляю сложности, жертвуя производительностью ради выгоды в хранилище данных и опциях определения пользователя.

Что ты думаешь?

1 Ответ

1 голос
/ 13 апреля 2010

Я не думаю, что это хороший путь, потому что:

  • Простая вставка из 1 записи для контакта внезапно становится n вставками. например если вы сохраняете данные контакта varchar, nvarchar, int, bit, datetime, smallint и tinyint для контакта, то это 7 вставок в конкретные таблицы типов данных, +1 для записи основного заголовка
  • Аналогично, запрос будет автоматически ссылаться на 7 таблиц, в которых задействовано 6 JOIN, чтобы получить полную информацию

Лично я считаю, что лучше пойти на менее "общий" подход. Сохраняйте это простым.

Обновление: Вопрос в том, нужно ли вам такое гибкое решение? Для контактных данных вы всегда ожидаете, что сможете хранить хотя бы основной набор полей (адресная строка 1-n, имя, фамилия и т. Д.). Если вам нужен способ хранения пользовательских / определяемых пользователем данных поверх этого стандартного набора данных, это общее требование. Различные варианты включают в себя:

  • Столбец XML в главной таблице контактов для хранения всех пользовательских данных
  • 1 дополнительная таблица, содержащая данные пары ключ-значение, немного такие, о которых вы говорили ранее, но в гораздо меньшей степени! Он будет содержать ключ контакта, имя пользовательского элемента данных и значение.

Они уже обсуждались здесь, на SO, поэтому стоит поискать этот вопрос. Похоже, я не могу найти вопрос, который я помню после быстрого взгляда!

Найдены некоторые, в которых обсуждаются плюсы и минусы подхода «ключ-значение», чтобы не повторяться:
Пары ключ-значение в реляционной базе данных
Пары ключ / значение в таблице базы данных

...