Иерархическая база данных, несколько таблиц или столбец с родительским идентификатором?

Question

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

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

Каковы плюсы и минусы любого решения? (с точки зрения эффективности конструкции)

Answer 1

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

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

Решение для отдельной таблицы будет намного проще в использовании.

Answer 2

три разных стола:

• более эффективно, если ваше приложение в основном обращается к информации только об одном объекте (округ, муниципалитет, город)
• отношения владелец-член - это четкая и элегантная модель;)

Answer 3

County, Municipality и City не похожи на данные одного типа; Итак, я бы использовал три разные таблицы: по одной на тип данных.

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

Говоря об эффективности, не уверен, что это сильно изменится:

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

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

Answer 4

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

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

Answer 5

Разные таблицы: это просто "правильно". Я сомневаюсь, что вы увидите какие-либо выигрыши / потери в производительности в любом случае, но именно в этом случае правильное предварительное моделирование, вероятно, сэкономит вам много головной боли в дальнейшем. С одной стороны, это облегчит написание и чтение SQL SELECT.

Answer 6

Я бы поместил их в три разных таблицы, только на том основании, что это 3 разных понятия. Это будет препятствовать скорости и усложнит ваши запросы. Однако, учитывая, что MySQL не имеет какой-либо специальной поддержки иерархических запросов (например, Oracle connect с помощью оператора ), это все равно будет сложно.

Answer 7

Я бы порекомендовал использовать три разные таблицы, так как это три разные сущности.

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

Answer 8

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

Answer 9

В приложениях с информационным наполнением приверженцы методологии Kimball могут поместить эти поля в одну таблицу атрибутов:

create table city (
   id int not null, 
   county varchar(50) not null,
   municipality varchar(50),
   city varchar(50),
   primary key(id) 
);

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

Я просто заявляю, что это альтернативный взгляд. Я бы лично подошел к дизайну 3 столов.

Answer 10

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

Это также упростит управление данными, так как вы сможете определить, предназначены ли данные для города, муниципалитета или округа, просто зная таблицу (и не обнаруживая «глубину» сначала запись в иерархии!).

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