Как спроектировать БД с отношениями родитель-ребенок?

Question

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

Решение, которое приходит на ум, таково:

===========================
| Id | ParentId | Name    |
===========================
| 1  | 0        | USA     |
---------------------------
| 2  | 1        | Alabama |
---------------------------

Мне интересно, есть ли потенциальные проблемы с таким решением. Спасибо.

Answer 1

Если вы знаете разные типы предметов (страны-государства города), вам следует создать отдельные таблицы.Помещение их всех в одну таблицу усложнит запрос.

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

Подумайте о детях!

Answer 2

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

Answer 3

Я использую нечто подобное и добился большого успеха с этим. Недавний мой вопрос может пригодиться.

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

Answer 4

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

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

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