Таблица наследник. | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Есть некая таблица, с ней завязана некая логика.
Есть еще таблица, которая практически дублирует эту, и логика на 90% схожа. 2й вариант реализации. Все поместить в одну таблицу, и общая логика, автоматом становится общей, записи разделить по некому признаку (назовем - categ). И отличающуюся логику, реализовывать глядя на categ. Очевидно - мало инфы. Но все описывать, бумаги не хватит) Кто как решает аналогичные варианты? ------------------ |
Re: Таблица наследник. | |
---|---|
Crispy Сообщений: 18571 Дата регистрации: 16.05.2005 |
Второй, на мой взгляд, будет несколько проблемней и в обработке, и в перспективе (если появится третья таблица, четвертая?).
Трудно конечно судить о самой задаче, но если речь о смене правил по дате (как часто бывает), логичнее например в проверку даты для обработки просто включить кейс, выбирающий по условию нужную таблицу. Впрочем, в любом случае "на местах" как говорится виднее. ;) ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери) |
Re: Таблица наследник. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
По разному решают. Начиная с того что "таблица" и "логика" это совершенно разные сущности.
А так - это классический вопрос ORM (объектно-реляционного маппинга) по способу хранения в РСУБД иерархии наследования. docs.jboss.org 3 основных стратегии, с несколькими "смешанными подвидами". - Таблица на всё (обычно с использованием дискриминатора). - Таблица на каждый "конкретный" класс (без единой таблицы на все классы - т.е. по сути таблицы независимы, даже если используют один сквозной нумератор id). - Таблица на "общую часть" и по таблице на каждый "конкретный" (только "специфика" отличающая классы-наследники от родителя в них). ------------------ WBR, Igor |
Re: Таблица наследник. | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Спасибо ребята.
Собственно этот вопрос уже решил. 2 таблицы будет. это разные сущности, из одной данные переносятся в другую, и там могут быть отредактированы. А вот с деталями - думаю одну сделать. Просто в таблице будет 2 поля, с указателями на свой мастер. Там железно все одинаково! Просто мастер разный. ------------------ |
Re: Таблица наследник. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Тогда лучше всё же либо одна (совмещающая ВСЕ поля - как одного, так и второго подклассов, к сожалению придётся их делать nullable/необязательными к заполнению, и проверять уже не средствами БД а кодом), либо 3 таблицы (одна с общими полями, и 2 с тем чем "различаются" эти подклассы). Именно для того чтобы можно было таблицу "детали" адекватно связать с одной таблицей. А не "2 поля со ссылками на разные мастер-таблицы". Это как раз очень плохое проектное решение.
------------------ WBR, Igor |
Re: Таблица наследник. | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
СУБД не указал. В некоторых есть механизм наследования таблиц. Правда констрейнты надо настраивать для каждого наследника отдельно.
|
Re: Таблица наследник. | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
MS SQL 2017
Игорь Совсем не понял твоего предложения. Но сейчас есть 2 похожих таблицы. Он мастер. И для них 1 таблица деталей. Просто там 2 поля nullable С указателем на мастера. Дело в том, что у деталей, абсолютно одинаковый функционал и смысл. ------------------ |
Re: Таблица наследник. | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
МастерМастер таблица. К ней вяжутся два твоих бывших Мастера. И детали вяжутся тоже к ней.
|
Re: Таблица наследник. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Предположим следующую структуру классов данной предметной области (предельно упрощённо):
Т.е. есть 2 разных класса с одинаковыми (по типу, не по содержимому) массивами детальной информации. "Общая" часть этих классов прописана в абстрактном (объектов такого класса никогда не будет существовать) классе AbstractMaster, а то чем они различаются - в 2 разных "конкретных" классах (именно такие объекты и будут существовать в системе). Естественно помимо "свойств" в каждом из классов есть и своя логика - она так же разделена для Master на 3 части - общая, и по 2 "специфичных" для подклассов. Эта структура может отображаться в РСУБД 3-мя разными способами, как я писал выше. НО т.к. тут есть "подчинённая" сущность, то один из способов будет плох, он не позволит сделать адекватные констрейны. Оставшиеся два способа это: 1) Одна таблица на все классы:
Поле Discriminator во втором случае необязательно, т.к. определить "конкретный класс" можно по наличию связанной записи в одной из "уточняющих" таблиц - либо в MasterWithNumber либо в MasterWithString - но оно (это поле) позволяет ускорять и упрощать некоторые типы запросов. Вариант с "таблица на каждый конкретный класс" - как ты хотел сделать - не позволит сделать очевидный, простой и хорошо работающий констрейн между Detail и Master/AbstractMaster - и это плохо. Два поля, контроль что заполнено только одно из них, и что ИМЕННО одно заполнено, два FK констрейна... В общем некрасиво и плохо. P.S. Отформатировал немного. ------------------ WBR, Igor Исправлено 1 раз(а). Последнее : Igor Korolyov, 23.11.17 13:33 |
Re: Таблица наследник. | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Паша, Игорь спасибо за идею. За подробное изложение теории, отдельное спасибо)
Прямо за меня 80% работы проделал. Есть о чем подумать. Хотя и вряд ли пойду на это. два FK констрейна плохо, но не пугают) Просто по неволе, на скорую руку, когда слепили такое, и много лет работает (вовсе не оправдываю некрасивость) И с этим легко разбираться. легко что то менять. Схема Игоря - великолепна! Но надо ее помнить и знать. И не только мне. А иногда, надо супер срочно что то найти, поменять, усовершенствовать. Но есть над чем подумать, поэксперементировать... ------------------ |
Re: Таблица наследник. | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Заставили задуматься.
Попробую подробнее все описать. Боюсь, ой много букв получится. Речь о заказах. Их много уровней. Есть самые оперативные, то с чем работают те кто отпускает. (Диспетчерская) Это самый нижний уровень. На нем все заканчивается. Заносят их, как сами юзеры, но так же, они поступают из различных мест. (речь об информационных местах) Есть интернет магазин. Своя БД. И через сложные манипуляции, заказы от туда, попадают в диспетчерскую. Есть личный кабинет клиентов. (Для тех кто постоянно, неоднократно) Опять своя БД. Структура иная, но уже ближе к нашей. И так же, через некие манипуляции, заказы поступают в диспетчерскую. В рабочей БД кроме оперативных заказов, есть предварительные заказы, там указана дата, и можно занести на завтра, на любую дату. От туда все переносится в оперативную. И очень похожая, но как бы, без даты. Скажем "Постоянные" заказы. Туда заносят заказы, которые длятся долго (дороги строим, потому заказ может длиться и неделю, и месяц) От туда, заказы переносят как в оперативный, так и в предварительный. Вот такая... мутная петрушка) Накидал схемку [attachment 28583 ] Упустил. Из статичного в предварительный тоже передается. ------------------ Исправлено 1 раз(а). Последнее : Аспид, 24.11.17 13:11 |
© 2000-2024 Fox Club  |