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

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

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

Вот несколько советов для начала:

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

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

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

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

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

Если имеется большое количество многозначных атрибутов, комбинация 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. Это означает, что одного WeightClass достаточно, чтобы определить ShipCost и ShipCost должны быть исключены из таблицы Part.

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

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

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

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

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

Таблица 1: PersonalDetails Таблица 2: Действия Таблица 3 Разное

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

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

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

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

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

https://stackoverflow.com/questions/tagged/normalization

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

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

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

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

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

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

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