Таблицы в наборе данных. Количество и избыточность

Question

Существуют ли передовые практики, касающиеся количества таблиц, используемых в наборе данных? В реляционной базе данных все таблицы в конечном итоге связываются, поэтому насколько конкретным или широким я должен быть при создании моих наборов данных?

Пример: если у меня есть набор данных для заказов на продукты, должен ли я также включать таблицы продуктов, а также таблицы клиентов, которым принадлежат заказы, таблицы с информацией о доставке и т. Д .; или я должен просто иметь базовую таблицу производителей и связанные таблицы поиска?

Answer 1

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

Answer 2

Я не могу сказать, является ли это лучшей практикой или нет, но там, где я работаю, у нас есть наборы данных с более чем 75 таблицами, которые работают очень хорошо. Некоторые из таблиц представляют собой всего лишь несколько записей, но в некоторых есть тысячи записей. Мы используем бинарное удаленное взаимодействие для транспортировки этих таблиц. Не уверен, что сериализация XML даст нам такую ​​же (или даже близкую к той же) производительности. В прошлый раз, когда я проверял размер нашего самого большого набора данных, сериализованного на диск, он был около 3 МБ.

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

Answer 3

"я должен также включить ... или я должен просто"

Каковы ваши варианты использования? Что люди будут делать с вашими данными? Это определяет проблемную область. Он точно определяет, какие данные должны присутствовать.

Читать это: http://www.ibm.com/developerworks/web/library/wa-dbdsgn1.html

Дополнительные примечания.

Во-первых, таблица должна отображаться на каждую реальную вещь в проблемной области. Спросите своих пользователей, что они делают, какие решения они принимают, какие действия они предпринимают. Это определит, какие реальные вещи требуют таблиц.

Заказ - это вещь. Заказанный товар - это вещь. Клиент это вещь.

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

Строка в заказе - это вещь, связанная с заказом.

Особенностью товара является вещь, относящаяся к товару в целом.

Этот процесс "нормализации" дает точные и полные правила для определения реляционной базы данных. Он точно сообщает, сколько таблиц вам понадобится для представления реальных вещей в вашей проблемной области.

Answer 4

Я использовал для разделения модели в разных наборах данных.
Однако это укусило меня довольно много раз.
Когда между таблицами в разных наборах данных существовала связь / ссылка, мне приходилось писать много кода «fixup».

Единственные 2 проблемы с одним большим набором данных imo - это медленный дизайн и медленное создание объектов. (несколько мс)

Второе не проблема для меня, так как я использую 1 набор данных на единицу работы.

Answer 5

Разделить его на основе использования / логических областей Если вы используете несколько таблиц вместе, сделайте это вместе. Если некоторые данные являются только справочными данными, то, вероятно, они должны перейти в другой набор данных ... Если вы работаете с заказами - загружайте только то, что необходимо.

В любом случае, может быть, вы хотели бы взглянуть на более удобные методы доступа к данным, например, на ORM? Попробуйте взглянуть на NHibernate и посмотреть, подходит ли он вашим сценариям ...