Добавление внешних ключей в дочерних элементах к «супер-родителю» - есть ли лучший способ, как представление?

Question

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

Итак, вот текущая база данных / структура orm

masterparent-> child1-> child2-> child3-> child4-> child5-> ребенка6

всегда oneToMany

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

nail-> getFingerPart () -> getFinger () -> getHand () -> getHuman () (и предположим, что у каждого fingerPart может быть несколько гвоздей;))

Моя задача теперь состоит в том, чтобы добавить столбец human_id к «nails», «finger_parts» и «finger» (а не просто к «hand», имеющему его).

Основными причинами этого являются многочисленные соединения, чтобы получить все ногти от человека и так далее. И "горячие клавиши" сущностей, такие как human-> getNails (), также выглядят довольно уродливо: foreach this-> getHands () как hand ... foreach hand-> getFingers () ...)

Хотя я не думаю, что это было бы большой проблемой производительности (это не высокопроизводительное приложение, где каждая мс имеет значение), но да, эти объединения раздражают, и 5-6 вложенных циклов не позволяют влюбиться в код.

Но я не знаю, это просто неправильно.

1.) Думаю, у вас возникнут проблемы с каскадным удалением в доктрине.

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

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

Есть ли здесь другие "конфликты", которые могут произойти?

Нет ли лучшего способа, как создать представление для этого? А затем HumanView-> findAllBy (["human": 1]); получить все гвозди (но с «настоящими» записываемыми сущностями, а не только для чтения)?

Answer 1

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

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

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

ПРОФИ

• Высокоскоростные запросы.
• Простые и короткие запросы с меньшим количеством кода. Легче читать и писать.

CONS

• Избыточность. И об этом много статей.
• Каждую отдельную модификацию данных теперь необходимо выполнять для транзакции , поскольку она всегда будет включать несколько обновлений / удалений.
• Много кода даже для простой модификации данных.
• Все разработчики должны понимать и делать это правильно.
• Ох ... приходит новое приложение, которое использует базу данных, и это новая команда, которая будет вносить изменения в нее. Они знают, как это сделать правильно? Вы им доверяете?
• Возможно, вам нужно написать ночные процессы, которые будут проверять / исправлять избыточность.

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

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

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