:: Не фоксом единым
Таблица наследник.
Аспид
Автор

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Есть некая таблица, с ней завязана некая логика.
Есть еще таблица, которая практически дублирует эту, и логика на 90% схожа.

2й вариант реализации.
Все поместить в одну таблицу, и общая логика, автоматом становится общей, записи разделить по некому признаку (назовем - categ).
И отличающуюся логику, реализовывать глядя на categ.

Очевидно - мало инфы. Но все описывать, бумаги не хватит)
Кто как решает аналогичные варианты?


------------------
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Crispy

Сообщений: 18571
Дата регистрации: 16.05.2005
Второй, на мой взгляд, будет несколько проблемней и в обработке, и в перспективе (если появится третья таблица, четвертая?).
Трудно конечно судить о самой задаче, но если речь о смене правил по дате (как часто бывает), логичнее например в проверку даты для обработки просто включить кейс, выбирающий по условию нужную таблицу. Впрочем, в любом случае "на местах" как говорится виднее. ;)


------------------
В действительности все иначе, чем на самом деле.
                                      (Антуан де Сент-Экзюпери)
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
По разному решают. Начиная с того что "таблица" и "логика" это совершенно разные сущности.
А так - это классический вопрос ORM (объектно-реляционного маппинга) по способу хранения в РСУБД иерархии наследования.
docs.jboss.org
3 основных стратегии, с несколькими "смешанными подвидами".
- Таблица на всё (обычно с использованием дискриминатора).
- Таблица на каждый "конкретный" класс (без единой таблицы на все классы - т.е. по сути таблицы независимы, даже если используют один сквозной нумератор id).
- Таблица на "общую часть" и по таблице на каждый "конкретный" (только "специфика" отличающая классы-наследники от родителя в них).


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Аспид
Автор

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Спасибо ребята.
Собственно этот вопрос уже решил.
2 таблицы будет. это разные сущности, из одной данные переносятся в другую, и там могут быть отредактированы.

А вот с деталями - думаю одну сделать.
Просто в таблице будет 2 поля, с указателями на свой мастер.
Там железно все одинаково!
Просто мастер разный.


------------------
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Тогда лучше всё же либо одна (совмещающая ВСЕ поля - как одного, так и второго подклассов, к сожалению придётся их делать nullable/необязательными к заполнению, и проверять уже не средствами БД а кодом), либо 3 таблицы (одна с общими полями, и 2 с тем чем "различаются" эти подклассы). Именно для того чтобы можно было таблицу "детали" адекватно связать с одной таблицей. А не "2 поля со ссылками на разные мастер-таблицы". Это как раз очень плохое проектное решение.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Таблица наследник.
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
СУБД не указал. В некоторых есть механизм наследования таблиц. Правда констрейнты надо настраивать для каждого наследника отдельно.
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Аспид
Автор

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
MS SQL 2017
Игорь
Совсем не понял твоего предложения.
Но сейчас есть 2 похожих таблицы. Он мастер.
И для них 1 таблица деталей.
Просто там 2 поля nullable
С указателем на мастера.

Дело в том, что у деталей, абсолютно одинаковый функционал и смысл.


------------------
Ratings: 0 negative/0 positive
Re: Таблица наследник.
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
МастерМастер таблица. К ней вяжутся два твоих бывших Мастера. И детали вяжутся тоже к ней.
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Предположим следующую структуру классов данной предметной области (предельно упрощённо):
abstract class AbstractMaster
int Id,
string Name,
date CreationDate
List<Detail> Details
class MasterWithNumber : AbstractMaster
double SomeNumber
class MasterWithString : AbstractMaster
string DocumentText
class Detail
int Id
string Title

Т.е. есть 2 разных класса с одинаковыми (по типу, не по содержимому) массивами детальной информации. "Общая" часть этих классов прописана в абстрактном (объектов такого класса никогда не будет существовать) классе AbstractMaster, а то чем они различаются - в 2 разных "конкретных" классах (именно такие объекты и будут существовать в системе). Естественно помимо "свойств" в каждом из классов есть и своя логика - она так же разделена для Master на 3 части - общая, и по 2 "специфичных" для подклассов.

Эта структура может отображаться в РСУБД 3-мя разными способами, как я писал выше. НО т.к. тут есть "подчинённая" сущность, то один из способов будет плох, он не позволит сделать адекватные констрейны.
Оставшиеся два способа это:
1) Одна таблица на все классы:
create table Master (Id int PRIMARY KEY, Name string, CreationDate date, SomeNumber double NULL, DocumentText string NULL, Discriminator string)
create table Detail (Id int PRIMARY KEY, Title string, MasterId int REFERENCES Master(Id))
2) Таблица на каждый класс:
create table AbstractMaster (Id int PRIMARY KEY, Name string, CreationDate date, Discriminator string)
create table MasterWithNumber (Id int PRIMARY KEY REFERENCES AbstractMaster(Id), SomeNumber double)
create table MasterWithString (Id int PRIMARY KEY REFERENCES AbstractMaster(Id), DocumentText string)
create table Detail (Id int PRIMARY KEY, Title string, MasterId int REFERENCES AbstractMaster(Id))
Связь с "деталями" всегда однозначна, и идёт на ОДНУ таблицу.
Поле Discriminator во втором случае необязательно, т.к. определить "конкретный класс" можно по наличию связанной записи в одной из "уточняющих" таблиц - либо в MasterWithNumber либо в MasterWithString - но оно (это поле) позволяет ускорять и упрощать некоторые типы запросов.

Вариант с "таблица на каждый конкретный класс" - как ты хотел сделать - не позволит сделать очевидный, простой и хорошо работающий констрейн между Detail и Master/AbstractMaster - и это плохо. Два поля, контроль что заполнено только одно из них, и что ИМЕННО одно заполнено, два FK констрейна... В общем некрасиво и плохо.

P.S. Отформатировал немного.


------------------
WBR, Igor




Исправлено 1 раз(а). Последнее : Igor Korolyov, 23.11.17 13:33
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Аспид
Автор

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Паша, Игорь спасибо за идею. За подробное изложение теории, отдельное спасибо)
Прямо за меня 80% работы проделал.
Есть о чем подумать.

Хотя и вряд ли пойду на это.
два FK констрейна плохо, но не пугают)
Просто по неволе, на скорую руку, когда слепили такое, и много лет работает (вовсе не оправдываю некрасивость)
И с этим легко разбираться. легко что то менять.

Схема Игоря - великолепна!
Но надо ее помнить и знать.
И не только мне. А иногда, надо супер срочно что то найти, поменять, усовершенствовать.
Но есть над чем подумать, поэксперементировать...


------------------
Ratings: 0 negative/0 positive
Re: Таблица наследник.
Аспид
Автор

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Заставили задуматься.
Попробую подробнее все описать. Боюсь, ой много букв получится.
Речь о заказах. Их много уровней.

Есть самые оперативные, то с чем работают те кто отпускает. (Диспетчерская)
Это самый нижний уровень. На нем все заканчивается.
Заносят их, как сами юзеры, но так же, они поступают из различных мест. (речь об информационных местах)

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

В рабочей БД кроме оперативных заказов, есть предварительные заказы, там указана дата, и можно занести на завтра, на любую дату.
От туда все переносится в оперативную.
И очень похожая, но как бы, без даты. Скажем "Постоянные" заказы.
Туда заносят заказы, которые длятся долго (дороги строим, потому заказ может длиться и неделю, и месяц)
От туда, заказы переносят как в оперативный, так и в предварительный.

Вот такая... мутная петрушка)
Накидал схемку

[attachment 28583 ]
Упустил. Из статичного в предварительный тоже передается.


------------------




Исправлено 1 раз(а). Последнее : Аспид, 24.11.17 13:11
Ratings: 0 negative/0 positive


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

On-line: 5 (Гостей: 5)

© 2000-2024 Fox Club 
Яндекс.Метрика