Что лучше - много маленьких столов или один большой стол?

Ответ 1

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

Ответ 2

Я в лагере Нормализации.

Вот несколько советов, которые помогут вам начать:

Начните с процесса, чтобы присвоить каждому произвольному уникальному идентификатору "человек". Назовите это PersonId или что-то в этом роде. Этот идентификатор называется суррогатный ключ. Единственной целью суррогатного ключа является гарантирует от 1 до 1 отношения между ним и реальным человеком в реальном мире. Использовать суррогатный ключ при связывании значения какого-либо другого атрибута с "человеком" в вашей базы данных.

По мере разработки макета базы данных вы можете найти суррогатные ключи, необходимые (или, по крайней мере, полезные) для некоторых других атрибутов.

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

Например, каждый человек имеет ровно одну "дату рождения". Но как может быть "Хобби" у них? Вероятно, ноль для многих. Однозначные атрибуты (например, дата рождения, высота, вес и т.д.) Являются кандидатами на общий стол с PersonId в качестве ключа. Количество атрибутов в каждой таблице не должно вызывают озабоченность в этот момент.

Многозначные атрибуты, такие как Хобби, должны немного отличаться лечение. Возможно, вам захочется создать отдельные таблицы для каждого многозначного атрибута. Использование Хобби как Например, вы можете создать следующую таблицу PersonHobby(PersonId, Hobby). Строка в этой таблице может выглядеть что-то вроде: (123, "Stamp Collecting"). Таким образом, вы можете записать столько хобби, как требуется для каждого человека, по одному в строке. Сделайте то же самое для "Interest", "Skill" и т.д.

Если существует немало многозначных атрибутов где комбинация PersonId + Hobby не определяет ничего другого (т.е. у вас нет ничего интересного для записи об этом человеке, который делает это "Хобби" или "Интерес" или "Умение" ), вы можете таблица атрибута-значения со структурой, подобной PersonAV(PersonId, AttributeName, Value). Здесь строка может выглядите так: (123, "Hobby", "Stamp Collecting").

Если вы идете по этому маршруту, также неплохо заменить AttributeName в таблице PersonAV для суррогатного ключа и создать другую таблицу, чтобы связать это ключ к его описанию. Что-то вроде: Attribute(AttributeId, AttributeName). Строка в этой таблице будет выглядеть примерно так: (1, "Hobby") и соответствующая строка PersonAV может быть (123, 1, "Stamp Collecting"). Это обычно делается так, что если вам когда-либо понадобится знать, какие AttributeNames действительны в вашей базе данных/приложении у вас есть место, чтобы найти их. Подумайте, как вы можете проверить, является ли "интерес" действительным значением для AttributeName или нет - если вы не записали какого-либо человека, имеющего этот AttributeName, тогда нет записи о том, что AttributeName в вашей базе данных - откуда вы знаете, должно ли оно существовать или нет? Посмотрите его в таблице Attribute!

Некоторые атрибуты могут иметь несколько взаимосвязей, и это тоже будет влиять на нормализацию таблиц. Я не см. любую из этих зависимостей в вашем примере, поэтому рассмотрим следующее: предположим, что у нас есть склад полный частей, PartId определяет его WeightClass, StockCount и ShipCost. Это предлагает таблицу что-то вроде: Part(PartId, WeightClass, StockCount, ShipCost). Однако, если существует связь между не-ключевые атрибуты, то они должны быть учтены. Например, предположим WeightClass напрямую определяет ShipCost. Это означает, что для определения ShipCost достаточно WeightClass, а ShipCost следует учитывать из таблицы Part.

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

Я призываю вас потратить время на еще немного изучите нормализацию, прежде чем строить свою базу данных. Несколько дней, проведенных здесь будет больше, чем платить за себя по дороге. Попробуйте выполнить поиск в Google/Wikipedia. "Функциональная зависимость", "Нормализация" и "Дизайн базы данных". Читайте, учитесь, учитесь, а затем стройте его правильно.

Предложения, которые я сделал в отношении нормализации дизайна вашей базы данных, - это только намек на то направление, которое вам может потребоваться. Без сильного понимания всех данных, которые вы пытаетесь управлять в своем приложении, любые рекомендации, приведенные здесь, должны быть взяты с "зерном соли".

Ответ 3

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

Ответ 4

Если у каждого человека одинаковое количество хобби (у IE есть всего 2 хобби), его нужно нормализовать.

Поля, которые всегда от 1 до 1 с человеком, должны находиться в одной таблице. Например, возраст. У человека не будет двух разных возрастов.

Ответ 5

IMO, более важно беспокоиться о качестве хранимых данных, а не о том, сколько таблиц вам нужно.

Например, вам нужно отслеживать изменения? Если Джон был 5'2 "в январе 2007 года и 5'11" в октябре 2010 года, вы хотите знать? Если это так, вам нужно будет выделить человека с высоты на две таблицы.

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

Вы должны прочитать о разработке и нормализации базы данных (на этом сайте есть несколько отличных потоков).

fooobar.com/questions/tagged/...

Ответ 6

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

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

Таблица 1: PersonalDetails Таблица 2: Мероприятия Таблица 3: Разное

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

Ответ 7

Нет правильного ответа на этот вопрос, потому что он во многом зависит от того, когда и как вы собираетесь использовать свои данные, как часто он будет меняться и какой объем использования будет в базе данных.

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

Ответ 8

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

Ответ 9

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