![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Иерархия объектов в БД
jack128 © (2007-01-15 18:01:00)Есть некая иерархия объектов.
TParent = class
property Prop1;
property Prop2;
property Prop3;
end;
TChild1 = class(TParent)
property C1Prop1;
property C1Prop2;
end;
TChild2 = class(TParent)
property C2Prop1;
property C2Prop2;
end;
Вот всё это дело должно хранится в БД. Как?
A)
в одну таблицу запихнуть все поля в одну таблицу:
Prop1 Prop2 Prop3 C1Prop1 C1Prop2 C2Prop1 C2Prop2
соответственно часть полей будет всегду null'евыми. Неприятно это выглядит. С другой строны - все запросы - просты как валенок.
B)
Все свойства из TParent хранить в одной таблице, а для каждого наследника нарисовать доп. таблицу, в которой хранить специфические свойства + ссылка на базовую таблицу. Получаем тучу left join'ов если нужно получить разом все объекты(а такая необходимость есть) + для усложняется сохранение объектов в БД. Вобщем грустно это..
С)
На каждый Child - класс своя таблица. Типа
Child1Tlb (Prop1, Prop2, Prop3, C1Prop1, C1Prop2)
Child2Tlb (Prop1, Prop2, Prop3, C2Prop1, C2Prop2).
Ну это вообще не вариант - на самом деле, так как нужны FK на TParent.
Собственно как это обычно реализуется?
vlad-mal (2007-01-18 00:12:00) [1]
> jack128 © (15.01.07 18:01)
> Ну это вообще не вариант
> - на самом деле, так как нужны FK на TParent. Собственно
> как это обычно реализуется?
Собственно говоря, и так делается, и эдак.
Например, когда все дочерние таблички ссылаются на родителя.
Вовсе не нужно, для получений все объекты класса Parent, делать left join ко всей цепочке деток (так и недолго Out of Memory словить) - выбирайте пары: "идентификатор объекта" + "идентификатор класса" из таблички Parent.
Идентификатор класса - это признак в Parent - табличке, означающий, что объект Parent на самом деле является объектом класса Child_NN.
А чтобы получить данные конкрентного класса, по полученному Id в нужный момент выбирайте данных простым join цепочки Parent...Child_NN.
Или, если нужны данные свойств классов сразу, а не их адентификаторы - пусть все будет в одной табличке. В Delphi, хвала аллаху, одинарное наследование. И ничего страшного, если она почти вся будет состоять из Null-ов. Гигабайты ноне дешевы. Полей в одной табличке FB можно разместить о-о-о-чень много. И опять-таки, в этой табличке заведите признак, к какому классу относится эта запись. Тогда выборка нужной коллекции будет проста и быстра.
Как пример, можете посмотреть структуру базы, генерируемую Bold for Delphi. Там можно настраивать объектно-реляционное отображение несколькими вариантами.
Или загрузите себе InstantObject с http://sourceforge.net/project/showfiles.php?group_id=94747- бесплатно, просто и обычно сразу понятно (по сравнению с Bold).
То, что предлагает
> PEAKTOP © (15.01.07 18:49) [6]
- на самом деле вещь довольно опасная. Время выборки коллекции будет линейно от числа свойств класса (т.е. числу соединений). Довольно просто провести эксперимент, создав большую коллекцию объектов с большим числом свойств, и выбрать все. Будет не весело.
atruhin (2007-01-16 18:45:00) [2]Нет не протеворечу. Разница в том, что FB блокирует запись только по требованию,
да и появилась возможность блокировки не так давно. На эту тему много копий сломано.
И я не хочу устраивать очередную ветку какой сервер лучше, тем более это сервера
разных категорий и для разных задач.
Спор возник о конкретной особенности сервера Sergey13 © уже сказал что не так понял
вопрос и согласился. Думаю тему можно закрыть.
evvcom (2007-01-16 17:49:00) [3]> [34] atruhin © (16.01.07 17:01)
> но есть средства блокировать запись
Так все-таки они есть!
> то версионность не вводили бы во все сервера
так "версионность" или "чистую версионность"? Ты уж определись с понятиями. И судя по тому, что все-таки
> есть средства блокировать запись
то твое
> [32] atruhin © (16.01.07 16:22)
> В этом и особенность "чистых" версионников что они ее не блокирут
не верно? Ты ж сам себе противоречишь.
atruhin (2007-01-16 17:01:00) [4]> И в результате кто последний тот и папа?
Обычно да, но есть средства блокировать запись.
> Что-то мне тогда даже пробовать не хочется
Зря, если бы это было так плохо, то версионность не вводили бы во все сервера.
evvcom (2007-01-16 16:27:00) [5]> [32] atruhin © (16.01.07 16:22)
> В этом и особенность "чистых" версионников что они ее не
> блокирут, изменяй хоть в пятером одновременно
И в результате кто последний тот и папа? Что-то мне тогда даже пробовать не хочется "чистого" версионника :)
atruhin (2007-01-16 16:22:00) [6]> [30] evvcom © (16.01.07 15:56)
Сейчас начнется :)
Только не с моей стороны, я кроме FB ни с чем не знаком, по крайней мере настолько чтобы спорить.
> А как же ты хочешь изменять запись не блокируя ее?
В этом и особенность "чистых" версионников что они ее не блокирут, изменяй хоть в пятером одновременно,
каждый будет работать со своей версией записи.
Sergey13 (2007-01-16 15:57:00) [7]> [29] atruhin © (16.01.07 15:46)
Я просто не въехал, что вы про тригерную СЦ уже обсуждаете. 8-)
Я думал про простую форинкейную. Сори.
evvcom (2007-01-16 15:56:00) [8]> [29] atruhin © (16.01.07 15:46)
> насколько слышал ни Оракл, ни ... не являются чистыми
> версионниками
Сейчас начнется :)
Что есть версионник, и что есть блокировочник?
Так как ты написал в [21] и Оракл поведет себя аналогично. А как же ты хочешь изменять запись не блокируя ее? В винде тоже есть объекты синхронизации, они блокируют (приостанавливают) работу потока, винда тоже блокировочник?
atruhin (2007-01-16 15:46:00) [9]> [27] Sergey13 © (16.01.07 13:57)
> ИМХО, если бы ОБЕ транзакции в этом случае подтвердились
> (закоммитились) то транзакции были бы вообще не нужны, как
> ненужный рудимент.
Не понял, можно пояснить? Естественно они подтвердяться, тригера то без ошибок отработали!
> [28] evvcom © (16.01.07 15:36)
> Для Оракла пойдет?
Я не знаю Оракл, но наверное нет, насколько слышал ни Оракл, ни MSSQL не являются чистыми версионниками,
а описанная мною ситуация возникает только для версионников. Для блокировочников реализация ссылочной целостности
"вручную на тригерах" работает нормально.
evvcom (2007-01-16 15:36:00) [10]> [13] Ega23 © (15.01.07 19:16)
> а во-вторых, у шефа откуда-то предубеждение насчёт триггеров...
У моего шефа тоже были предубеждения. Я их поломал. :)
> [5] Ega23 © (15.01.07 18:38)
> 3. Каждый неабстрактный класс имеет собственную таблицу с именем
Зачем? Это для хранения значений? По-моему вполне достаточно одной таблицы.
> [22] atruhin © (15.01.07 20:43)
> Вообще это общеизвестный факт работы версионников.
Я бы это назвал общеизвестным фактом работы кривых рук. Я, конечно, не знаю FB, а в Оракле для этого есть инструменты.
> [25] jack128 © (15.01.07 23:01)
> ЗЫ а на счет встретится - это можно.
Ах вот что послужило причиной пятничной MMP :)
> Если вы не согласны приведите пример корректно работающего
> тригера т.е. возможность обеспечить
> ссылочную целостность обычными тригерами
Для Оракла пойдет?
Sergey13 (2007-01-16 13:57:00) [11]> [21] atruhin © (15.01.07 20:42)
> 6. Транзакции подтверждаются, целостность нарушена.
ИМХО, если бы ОБЕ транзакции в этом случае подтвердились (закоммитились) то транзакции были бы вообще не нужны, как ненужный рудимент.
atruhin (2007-01-16 13:45:00) [12]> [23] Johnmen © (15.01.07 20:56)
> Данный пример никакого отношения к "ВНЕ контекста" не имеет.
> А лишь иллюстрирует один из способов изоляции транзакций.
Данный пример иллюстрирует невозможность обеспечения ссылочной целостности на тригерах.
Если вы не согласны приведите пример корректно работающего тригера т.е. возможность обеспечить
ссылочную целостность обычными тригерами (работающими в контексте текущей транзакции)
> Просьба указать источник сего факта. М.б. я что-то пропустил
> в своё время...
Источник не укажу, данный вопрос неоднократно поднимался на разных форумах, и обсуждался,
в том числе с разработчиками FB. Например SQL.RU
jack128 (2007-01-15 23:01:00) [13]Petr V. Abramov © (15.01.07 22:37) [24]
Не, нафиг мне эти dfm/скрипты. До скриптов в базе я еще не дорос. Нет необходимости.
Ну вобщем выводы сделаны. Всем спасибо.
ЗЫ а на счет встретится - это можно.
Petr V. Abramov (2007-01-15 22:37:00) [14]> jack128 ©
Женя, ты хочешь сделать хранение dfm-ников в БД?
ну так и скажи и переведи в потрепаться, там идей ьрльше будет, потому что идея хорошая, и не ты первый придумал и не последний
Johnmen (2007-01-15 20:56:00) [15]
> atruhin © (15.01.07 20:42) [21]
Данный пример никакого отношения к "ВНЕ контекста" не имеет. А лишь иллюстрирует один из способов изоляции транзакций.
> atruhin © (15.01.07 20:43) [22]
> Вообще это общеизвестный факт работы версионников.
Просьба указать источник сего факта. М.б. я что-то пропустил в своё время...
atruhin (2007-01-15 20:43:00) [16]Вообще это общеизвестный факт работы версионников.
atruhin (2007-01-15 20:42:00) [17]> [20] Johnmen (15.01.07 20:31)
> ВНЕ контекста только генераторы.
> ВСЁ остальное в контексте. Да по-другому и быть не может.
Вы неправы. Простой пример:
1. Есть таблицы Master, Detail
2. Пользователь_1 открыл Транзакцию_1
3. Пользователь_2 открыл Транзакцию_2
4. Пользователь_1 проверяет, что для записи X Master таблицы, нет записей в таблице Detail, и удаляет ее
5. Пользователь_2 вставляет в таблицу Detail запись ссылающуюся на запись X таблицы Master, происходит проверка в тригере,
тригер видит версию записи на начало транзакции, запись вставляется.
6. Транзакции подтверждаются, целостность нарушена.
Johnmen (2007-01-15 20:31:00) [18]
> atruhin © (15.01.07 19:33) [19]
> На тригерах то на тригерах, только эти внутренние тригера
> работают ВНЕ контекста транзакций.
ВНЕ контекста только генераторы.
ВСЁ остальное в контексте. Да по-другому и быть не может.
> Пользовательские тригера работают в контексте транзакции,
> поэтому на версионнике обеспечить
> ссылочную целостность, пользовательскими тригерами вроде
> нельзя.
В данном случае "внутренние" НИЧЕМ не отличаются от "пользовательских".
> Ega23 © (15.01.07 19:29) [16]
> > Именно на триггерах ФК и реализованы!
> Здесь другое, здесь за ссылочной целостностью самому придётся
> следить.
Ес-но. И это слежение ничем не хуже, если не самому.
atruhin (2007-01-15 19:33:00) [19]> [15] Johnmen (15.01.07 19:25)
> Именно на триггерах ФК и реализованы!
На тригерах то на тригерах, только эти внутренние тригера работают ВНЕ контекста транзакций.
Пользовательские тригера работают в контексте транзакции, поэтому на версионнике обеспечить
ссылочную целостность, пользовательскими тригерами вроде нельзя.
Ega23 (2007-01-15 19:31:00) [20]
> В итоге примерно полгода затраченные на доводку структуры
> БД, написание компонентов и
> каркаса программы, окупаются с лихвой.
>
Это точно. Вот только как сложно это было с самого начала шефу объяснить... :о)