|
|
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Кто использовал в своей практике OID. Поделитесь пожалуйста (+/-). Заранее спасибо. -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 12:46 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
у меня правило - абсолютно все объекты имеют неизменяемый ID, причем для некоторых он скрытый а для других - видимый и по нему можно искать. Все ссылки между объектами только по ID. Никаких (-) пока не заметил. Успехов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:50 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
мод .... не изменяемый ID... Уникальный в пределах всей системы (базы)? Если да, то как различаешь объекты разных типов. Как с зависимостями? FK то не построишь. -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:53 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Уникальный внутри класса потому что для некоторых классов ID открыт. Хотя можно и сквозную нумерацию устроить. Если класс=таблица то с FK все в порядке в любом случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:34 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Но в таком случае, где же приимущества OID, если уникальность в прелелах таблицы. Все ссылки тогда фиксированные. Пример: есть класс матеиалы, есть класс изделия. Получается там где я ссылаюсь на материал, я не могу ссылаться на изделия. И надо писать код один к одному для разных классов (элементов таблиц). Так я и без OID могу. Если вести единую последовательность, то как получать typeinfo (если в самом OID - вопрос производительности). Раздельно (TYPEID,ID) - ИМХО более заманчивее. Как считаете? -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 17:08 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
StudSW где же приимущества OID OID нужен для того, чтобы при появлении нового объекта его раз и навсегда жестко идентифицировать, использовать OID во всех ссылках на этот объект и контролировать целостность ссылок (т.е. не удалять объект если есть ссылки). Тип объекта определяется не по OID, а по типу ссылки. Про изделия и материалы: не понял проблемы. Продажа - изделий, покупка -материалов, никакой путаницы. Но если надо иногда их объединяют в один класс с явным указанием типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 09:42 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
мод .... Тип объекта определяется не по OID, а по типу ссылки. .... Так какая же здесь разница в - можно ведь использовать обычную реляционную модель, т.е. - занчение превичного ключа. Про материалы и изделия пример вот в чем: 1. Материалы покупаются, изделия производятся, т.е. он разные по натуре и имеют отличительные наборы реквизитов. 2. Но..., и материалы, и изделия участвуют в складских операциях (перемещение, списание, ...) 3. Есть производственные операции. В простом случае производство из материалов изделий. А в случае много ступенчатого производства (+Производство из изделий и материалов) + Есть необходимость добавления (бетонов, каркасов). Они все по определению различны, но имеют общие в некотором аспекте черты. -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 10:18 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Получается по твоему подходу необходимо использовать для каждого вида свой "документ" и заниматьсч копи-пастом. А если в документе могут участвовать две группы одновременно, тогда как? -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 10:20 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
OID это и есть первичный ключ (если класс=таблица) Оычно изделия, материалы, детали, сборки - это все один класс с подклассами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 10:25 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Хорошо, допустим OID уникален в пределах класса и подклассов. Как организовать "наследование"? Как получать информацию в какой именно подкласс входит объект? -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 10:41 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
StudSW Как получать информацию в какой именно подкласс входит объект? Атрибут Тип объекта = ссылка на классификатор типов, возможно иерархический ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 11:10 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Т.е. паралельно что бы по ссылке, получать TypeInfo надо ссылку оформлять в виде (TYPID,ID) что и будет в данном случае OID. Либо держать таблиуц OBJECTS, в которой по OID получать (TYPID,ID). Иерархию можно хранить в таблице CLASSES (TYPID,PARENTID,NAME,TABNAME,...), в которой подразумевать что все наследники должны иметь реквизиты родителей + свои. А всё правильно понял? Но всё равно остается вопрос зависимостей. Т.к. обычно СУБД по жестко определяют какая таблица с какой по какому связана. А необходимо, чтобы она по данным TYPID определяла к какой таблицы (т.е. классу) относитя объект. Ведь триггерная зависимость в много ползовательской среде не надёжна (выполняется в контексте транзакции). Не использовать же ту трехзвенку? -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 13:37 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
TypeID не исключает нормальные constraint'ы. Таблицы дочерних классов ссылаются на таблицы родителей (может и на одну корневую) по OID. Это гарантируется constraint'ом. Даже cascade update работать будет. А TypeID нужен когда тебе нужно УТОЧНИТЬ тип объекта. Например, узнать, является ли данный ОБЪЕКТ сотрудником. Или - сотрудник - руководителем подразделения (со специфическими свойствами). В принципе, TypeID может быть и не скаляром. Например, какое-то юрлицо проявляет свойства а) поставщика б) покупателя. Правда, так я никогда не делал, но может получиться интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 13:50 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
StudSWВедь триггерная зависимость в много ползовательской среде не надёжна Плюньте в лицо тому, кто сказал Вам такую глупость. Реализация ссылочной целостности триггерами - малоосмысленное извращение, но при прямых руках работать будет как надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 18:36 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
Вопрос не в кривости реализации, а в том что тригеры не могут заменять FK во всех случаях. Пример: одна транзакция удалила запись, но ещё не зафиксировна. А другая пытается сослаться на эту запись - тригер эту ситуацию не обработает (работает в контексте транзакций), а внешний ключ такого не допустит (работает вне транзакций). Другое дело, что с определёнными ограничениями можно полагаться и на тригерную целостность: вроде запрета изменения PK, запрета прямого удаления (только пометка), удаление (физическое) в монополном режиме. В принципе в таком режиме наверное и предется работать. А на счет иерархического представления классов - идея интересная. -- Учусь (пока/ещё) чего и вам желаю Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 21:16 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
StudSW Вопрос не в кривости реализации, а в том что тригеры не могут заменять FK во всех случаях. Чушь. StudSWа внешний ключ такого не допустит (работает вне транзакций). Чушь, причем очевидная и непродуманная. Это утверждение означает, что в одной транзакции невозможно вставить две записи, одна из которых ссылается на другую, либо удалить родительскую запись вместе с дочерними. StudSWУчусь (пока/ещё) чего и вам желаю Тогда учебное задание: реализовать триггерами полноценную ссылочную целостность между двумя таблицами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 22:26 |
|
||
|
Object ID
|
|||
|---|---|---|---|
|
#18+
StudSW Иерархию можно хранить в таблице CLASSES (TYPID,PARENTID,NAME,TABNAME,...), в которой подразумевать что все наследники должны иметь реквизиты родителей + свои. А всё правильно понял? Но всё равно остается вопрос зависимостей. Т.к. обычно СУБД по жестко определяют какая таблица с какой по какому связана. А необходимо, чтобы она по данным TYPID определяла к какой таблицы (т.е. классу) относитя объект. Если я правильно понял что имел ввиду автор, по поводу материалов и изделий. Все они являются ТМЦ(родитель), у которой в минимальном случае есть, к примеру, наименование и тип. Конкретный объект ТМЦ(наследник) имеет дополнительные свойства: цвет, вкус, прочность и т.д. Приведу три примера реализации хранения свойств наследников. 1. Избыточность данных, денормализация. Все объекты хранятся в одной таблице с полным перечнем возможных свойств, и сылкой на классификатор типов. При заполнении для нужного типа, заполняются нужные поля. 2. Объекты разных типов, хранятся в разных таблицах. Для поддержания целостности, создается табличка, которая хранит значения первичных ключей объектов. Причем, первичный ключ уникален в пределах таблиц объектов всех типов. При добавлении объекта любого типа, добавляется запись в таблицу первичных ключей. На эту таблицу ссылается та, которая содержит строки доукментов. 3. Все объекты хранятся в одной таблице с перечнем общих свойств, и ссылкой на классификатор типов. Тип имеет набор дополнительных свойств объекта. Эти свойства хранятся в отдельных таблицах, в зависимости от типа данных(или в одной, с денормализацией). При добавлении объекта, заполняется набор его свойств, предопределенный для типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 01:58 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=33632267&tid=1545340]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
158ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 425ms |
| 0 / 0 |
