Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 31   вперед  Ctrl
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод

Другое дело, что rowid в РСУБД надо бы довести до ума.


Каким образом?
Какие дополнительные особенности вы он него ожидаете,
что не устраивает?
17 ноя 06, 15:54    [3416364]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
!
Какие дополнительные особенности вы он него ожидаете,

1. не изменяемость ни при каких импортах-экспортах
2. возможность строить на них ссылочную целостность аналогично ФК
3. невозможность повторного использования после удаления (в этом не уверен)
17 ноя 06, 16:21    [3416619]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Еще раз повторю rowid это указатель на позицию(смещение) в таблице.
(в конкретном файле, конкретном сегменте, конкретном экстенте)

мод

1. не изменяемость ни при каких импортах-экспортах


При бэкапе ресторе он сохраняется.

При импорте или экспорте в гипотетической субд может тоже сохраняться
если экспортирутестся полностью вся схема с зарезервированными блоками
и прочими внутренними атрибутами и системным каталогом.
Что анлогично бэкапу.

мод

2. возможность строить на них ссылочную целостность аналогично ФК


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

Нужно пользоваться только бэкапом-рестором.


мод

3. невозможность повторного использования после удаления (в этом не уверен)


Невозможность повторного использования равносильно отказу
от повторного использования дискового пространства освободившегося
после удаления.

При выполнения этого правила rowid превращаяется в
первичный ключ генерируемый с помошью соответствующим образом настроенного
сиквенса.

У него первоочередная задача другая , он указатель на место
где хранится запись.
17 ноя 06, 16:46    [3416910]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
!

Ваш ответ только подтверждает то, что я и так знаю: ни одна из существующих РСУБД моим требованиям (по rowid) не удовлетворяет. Это вовсе не значит, что этими СУБД нельзя пользоваться :)
20 ноя 06, 11:53    [3423206]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
?
Добавьте PK числового типа с автоинкрементом ко всем таблицам. И тогда однонаправленная связь и будет реализована, как ссылка на PK. Скорость доступа при наличии индекса будет максимальной в прямом направлении. Остается вопрос с типизацией указателей: в РСУБД для указания сущности в произвольной таблице придется еще подкрутить, но это тоже делается.
Это всего лишь workaround не решающий проблемы в целом.
Во первых автоинкрементация не пройдет, т.к. для эмуляции указателей будет нужна сквозная нумерация. Следствием станет невозможность использования foreign keys и необходимость поддерживать ссылочную целостность триггерами. Ну это все еще можно вытерпеть. А вот трактовать таблицы как коллекции экземпляров объектов (когда один и тот же экземпляр может быть членом нескольких коллекций) при таком подходе ну совсем неэффективно. А эта функциональность требуется для моделирования наследования. Далее в РМД шапка таблицы (отношения) жестко определяет аттрибуты строки (кортежа). Это делает эту модель неэффективной при моделировании сущностей с динамически изменяемой номенкулатурой аттрибутов. Вобщем да, все это можно реализовать в РБД. Но надо по крайней мере быть честным перед самим собой, тогда эти БД станут сетевыми, а вовсе не реляционными. Ну этот процесс можно уже наблюдать на примере уродцев XML-SQL-DB. Через несколько лет все выровняется и РМД трансформируется в СМД.
20 ноя 06, 12:47    [3423734]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
мод
Эффективность реализации меня не интересует (пока).

Дьявол всегда скрыт в деталях.
мод
Когда меня не устраивала СБД, я моделировал РБД на СБД. Когда меня не устраивает РБД, я моделирую СБД на РБД. Ссылки к сожалению дать не могу, могу только дать совет попробовать, это не сложно.
Я это тоже делал. И даже приводил здесь ссылки на результаты. То что я здесь публикую - это моя точка зрения обоснованная результатами этих экспериментов.
20 ноя 06, 12:57    [3423825]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
мод
В сетевых БД каждая запись автом. получает rowid и он никогда не изменяется.
Не во всех.
20 ноя 06, 12:58    [3423835]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
RENaissance

З.Ы Интересуюсь с практической точки зрения, т.к. работаю с MSSQL, где понятие rowid отсутствует.
Они просто тоже самое назвали по другому, поищите bookmarks.
20 ноя 06, 13:00    [3423856]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895

shuklin

Они просто тоже самое назвали по другому, поищите bookmarks.

Спасибо. Но это я знаю. Дел в том, что из TSQL я не могу обратиться напрямую к bookmark'у (rowid). Но, собственно говоря, мне этого
и не требуется. Я могу воспользоваться полем IDENTITY, которое, IMHO, имеет большую функциональность.
З.Ы Хотел бы добавить, IMHO опять же, что IDENTITY-поле полностью соответствует тому, что хотел мод в
этом посте.
З.З.Ы В итоге, все-таки, я сомневаюсь в практической ценности rowid для разработчика.


Posted via ActualForum NNTP Server 1.3

20 ноя 06, 13:15    [3424022]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Сетевая модель - про память.
Реляционная - про данные независимо от формы памяти.

Вот и вся разница:)

СУБД не существуют вне памяти, но реляционные категорически отказываются обещать постоянство адресов (rowid) и идентифицировать данные иначе, чем собственно данными.
20 ноя 06, 17:25    [3425958]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ModelR
СУБД не существуют вне памяти, но реляционные категорически отказываются обещать постоянство адресов (rowid) и идентифицировать данные иначе, чем собственно данными.


Ну и чудненько, гвоздь в гроб

А если серьезно, при чем тут модель памяти? В графах что память какаято есть? Или в семантический сетях фреймов? Или в иерархических семантических сетях? Все это такие же застывшие вне времени структуры данных как и РМД.
20 ноя 06, 17:31    [3425985]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Ээ, а графы причем? графы суть множества и отношения на них.

Как идентифицировать узлы и соответсвенно дуги - опять таки вопрос отдельный.
РМД ответ: дать каждому узлу уникальное обозначение.
Сетевой: поместить каждый узел в отдельную область памяти.
20 ноя 06, 17:40    [3426056]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Кстати "1 ко многим" и пр. это не из РМД, это из ER.
Как все помнят, по замыслу авторов ER модель допускается реализовывать и сетями и отображать в РМД, и вообще куда угодно еще.
Для РМД "1 ко многим" - один из примеров полезных ограничений, которые можно поручить СУБД
отслеживать, написав соответсвующий предикат уровня БД.

Сорри за занудство, но зачем же каждый раз изобретать новую терминологию.
20 ноя 06, 17:56    [3426146]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ModelR
Ээ, а графы причем? графы суть множества и отношения на них.

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

ModelR
Как идентифицировать узлы и соответсвенно дуги - опять таки вопрос отдельный.
РМД ответ: дать каждому узлу уникальное обозначение.

Согласен.

ModelR
Сетевой: поместить каждый узел в отдельную область памяти.

Упс. Тут точно так же как и в РМД, тоже дать каждому узлу уникальное обозначение.

Разница более тонка.

СМД оперирует узлами и связями. Следовательно модели пофиг сколько и каких связей входит/выходит из узла. Сколько удобно в данном конкретном случае - столько и будет.

А вот в РМД номенкулатура аттрибутов в кортеже ограничена шапкой. Тоесть чтобы моделировать узел с неизвестной заранее номенкулатурой связей БД придется поворачивать на 90град и работать с извратами типа EAV. Судя по числу сломанных копий красивых решений этой задачи для РМД еще нет.

Если позволить добавлять в кортеж аттрибуты независимо от шапки, а шапку рассматривать как интерфейс к кортежу - вот тогда разница останется в идентифицируемости / идентичности / эквивалентности. Но даже если отбросить идентифицируемость с сотоварищами, шапка = интерфейс это ужо не РМД.
20 ноя 06, 17:56    [3426152]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ModelR
Кстати "1 ко многим" и пр. это не из РМД, это из ER.
Пасиба за наводку.
20 ноя 06, 17:59    [3426173]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
shuklin
СМД оперирует узлами и связями. Следовательно модели пофиг сколько и каких связей входит/выходит из узла.

Это как ? Связи закладываются в схему изначально, добавление новых связей влечет изменение схемы. В этом смысле никакой разницы между РБД и СБД нет и проблема "с извратами типа EAV" остается.[/quot]
shuklin
работать с извратами типа EAV. Судя по числу сломанных копий красивых решений этой задачи для РМД еще нет.

Красивых решений ни в рамках РБД, ни в рамках СБД нет. Они есть только в рамках списковых структур, но это совсем другая песня.
21 ноя 06, 10:09    [3427778]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
shuklin
ModelR
Сетевой: поместить каждый узел в отдельную область памяти.

Упс. Тут точно так же как и в РМД, тоже дать каждому узлу уникальное обозначение.

Разница более тонка.

СМД оперирует узлами и связями. Следовательно модели пофиг сколько и каких связей входит/выходит из узла. Сколько удобно в данном конкретном случае - столько и будет.
Где тонко, там однако аккуратней надо.

Уникальное обозначение СМД суть именно адрес, поскольку обладает замечательным свойством - доступ по нему "прямой", т.е быстрый. Посему его (адрес) мы и эксплуатируем в связях. А иначе чем бы оно (уникальное обозначение) отличалось от возможного ключа РМД?
И для чего бы весь огород?

Насчет пофиг опять вопрос отдельный - система типизирована или нет. Если нет, то это ИМХО уже где-то за пределами БД - просто контейнер узлов, в узле поток байтов данных плюс вектор ссылок на произвольные узлы. И одному приложению известно, что с этим делать. Если узлы и связи типизированы, то конечно СУБД не пофиг, что с чем и какой именно связью вязать.
21 ноя 06, 10:40    [3427986]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод
shuklin
СМД оперирует узлами и связями. Следовательно модели пофиг сколько и каких связей входит/выходит из узла.

Это как ? Связи закладываются в схему изначально, добавление новых связей влечет изменение схемы. В этом смысле никакой разницы между РБД и СБД нет и проблема "с извратами типа EAV" остается.

shuklin
работать с извратами типа EAV. Судя по числу сломанных копий красивых решений этой задачи для РМД еще нет.

Красивых решений ни в рамках РБД, ни в рамках СБД нет. Они есть только в рамках списковых структур, но это совсем другая песня.[/quot]

Если формализовать требования то с точки зрения синтаксиса
это должно выглядеть приблизительно так :
(или подругому? как?)

ctreate table_class classname1
(
field1 ...
field2 ...
field3 ...
)

ctreate table_class classname2 derived from classname1
(
field4 ...
field5 ...
)

ctreate table_class classname3 derived from classname1
(
fieldN ...
)

insert into  classname1 values( 1,2,3);
insert into  classname2 values( 201,202,203,204,205);
insert into  classname3 values( 301,302,303,304);

select * from classname1;
field1  field2 field3 
--------------------------------------
201     202  203
301     302  303
   1        2      3
--------------------------------------
3 rows selected

select * from classname2;
field1  field2 field3 
--------------------------------------
201     202  203
--------------------------------------
1 rows selected

........................

Но это не избавит систему от необходимости наличия PK & FK,
логику работы которые нет смысла делать отличными от РСУБД.
Если есть то почему?
21 ноя 06, 11:28    [3428372]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
мод

Это как ? Связи закладываются в схему изначально, добавление новых связей влечет изменение схемы. В этом смысле никакой разницы между РБД и СБД нет и проблема "с извратами типа EAV" остается.

Красивых решений ни в рамках РБД, ни в рамках СБД нет. Они есть только в рамках списковых структур, но это совсем другая песня.


Я конешно всех тут уже достал этой линкой, но всеже http://www.shuklin.com/ai/ht/ru/cerebrum/

По поводу обоих пунктов - там все в порядке. Как с добавлением связей, так и со схемами. И ИМХО это еще и красиво, очень.
21 ноя 06, 13:40    [3429532]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ModelR
Уникальное обозначение СМД суть именно адрес
И для чего бы весь огород?

Уникальное обозначение в СМД никогда адресом небыло. Это в ООСУБД объектные идентификаторы трактуют как адреса некоторого виртуального адресного пространства. Но т.к. это пространсво виртуально, к физическому хранению эти адреса никакого отношения не имеют. И во многих случаях реализованы способами категорически похожими на реализацию PK в РСУБД.

А огород ради другой модели данных, более удобно решаюих задачи для которых РСУБД мягко говоря не очень. Хранение тех же деревьев и сетей к примеру, без потери таблиц.

ModelR
Насчет пофиг опять вопрос отдельный - система типизирована или нет. Если нет, то это ИМХО уже где-то за пределами БД - просто контейнер узлов, в узле поток байтов данных плюс вектор ссылок на произвольные узлы. И одному приложению известно, что с этим делать. Если узлы и связи типизированы, то конечно СУБД не пофиг, что с чем и какой именно связью вязать.

Странно мне такое слышать сейчас, имея OLEVARIANT, sql_variant и System.Object в широкой эксплуатации. Сорри но суть тезиса я просто не понял. В чем проблемы наличия/отсутсвия типизации я не вижу. Нужна - будет, не нужна - не будет. пофиг.
21 ноя 06, 13:46    [3429577]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!

Но это не избавит систему от необходимости наличия PK & FK,
логику работы которые нет смысла делать отличными от РСУБД.
Если есть то почему?

С точностью до каких то мелких деталей - согласен.

Можно еще про 1NF поговорить, тогда еще немного изменений вылезет. Вобщем в итоге от таблица==отношение ничего не остается. А ведь для классической РМД это один из базовых постулатов.
21 ноя 06, 13:52    [3429619]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!

Но это не избавит систему от необходимости наличия PK & FK,
логику работы которые нет смысла делать отличными от РСУБД.
Если есть то почему?

С точностью до каких то мелких деталей - согласен.

Можно еще про 1NF поговорить, тогда еще немного изменений вылезет. Вобщем в итоге от таблица==отношение ничего не остается. А ведь для классической РМД это один из базовых постулатов.


Это смотря как дальше развивать идеологию поведения системы.

Есть 2 крайних случая.

1. N-ый уровень наследования представляет собой N-НФ с некоторыми ограничениями,
с автоматическим созданием и проверкой соответствующих внутренних
констрейнтов.
И проверкой данных при вставке.
Что аналогично РСУБД, только структура схемы будет более приближена к жизни.


2. Полностью денормализованная модель.

Вы в каком направлении предпочли бы двигаться?
21 ноя 06, 15:04    [3430155]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
!
(или подругому? как?)

Списки вместо таблиц.
!
Но это не избавит систему от необходимости наличия PK & FK,
логику работы которые нет смысла делать отличными от РСУБД.

Наличие rowid делает применение PK не нужным.
Наличие адресных ссылок делает применение FK не нужным.
21 ноя 06, 15:04    [3430158]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
мод
Наличие rowid делает применение PK не нужным.
Наличие адресных ссылок делает применение FK не нужным.

Я бы изменил формулировки:
Наличие rowid делает его PK
Наличие адресных ссылок делает их FK
21 ноя 06, 15:14    [3430247]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
shuklin
По поводу обоих пунктов - там все в порядке. Как с добавлением связей, так и со схемами. И ИМХО это еще и красиво, очень.

Охотно верю, но к сожалению не могу проверить - очень много букоф. Дело в том , что любая формальная модель данных м.б. описана на одном листке бумаге. У вас этого одного листка нет.
21 ноя 06, 15:19    [3430290]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить