Это хорошая практика для консолидации небольших статических таблиц в базе данных? - PullRequest
0 голосов
/ 19 мая 2011

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

Вот мой список таблиц с полями в каждой таблице:

Source Type - id, name, description
For Flight - id, name, description
Site - id, name, abrv, description
Stand - id, site (FK site table), name, abrv, descrition
Sensor Type - id, name, channels, descrition
Vehicle - id, name, abrv, descrition
Zone - id, vehicle (FK vehicle table), name, abrv, description
Event Type - id, name, description
Event - id, event type (FK to event type Table), name, descrition
Analysis - id, name, descrition
Bandwidth - id, name, descrition

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

Было бы лучше иметь только одну большую таблицу с именем Meta со следующими полями:

Meta: id, metavalue, name, abrv, FK, value, descrition

где metavalue = одно из названий таблицы выше
и FK = ссылка на другую строку в мета-таблице вместо внешнего ключа?

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

Итак, вопросы:

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

К вашему сведению, я создаю эту веб-базу данных, используя django и mysql на сервере Windows с форматированием NTFS.

Полезные советы и рекомендации.

спасибо.

Ответы [ 3 ]

4 голосов
/ 19 мая 2011

«Было бы лучше иметь только одну большую таблицу» - категорически и категорично, НЕТ!

Этот анти-паттерн иногда называют «Единой таблицей, которая управляет ими всеми»!

Десять распространенных ошибок проектирования баз данных : одна таблица для хранения всех значений домена.

  • Использование данных в запросе намного проще

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

  • Если окажется, что вам нужно хранить больше информации о ShipViaCarrier, чем просто код, «UPS» и описание «United Parcel Service», то это так же просто, как добавить столбец или два.может даже расширить таблицу, чтобы получить полное представление о компаниях, которые являются носителями данного элемента.

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

  • У вас все еще может быть один редактор для всех строк, так как большинство доменных таблиц, вероятно, будут иметь одинаковую базовую структуру / использование.И хотя вы потеряете возможность легко запрашивать все значения домена в одном запросе, зачем вам это?(При необходимости можно легко создать запрос на объединение таблиц, но это может показаться маловероятным.)

1 голос
/ 19 мая 2011

Это также часто называют One True Lookup Table (OTLT) - см. Мою старую запись в блоге OTLT и EAV: две большие ошибки проектирования, которые все новички совершают .

1 голос
/ 19 мая 2011

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

Поле в таблице ссылок просто хранит код. например: "SRC_FOO", "EVT_BANG" и т. д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...