Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
dimon_n2000

да, по поводу наследственности - тоже от лукавого. в природе наследуются только гены. еще имущество, но это бизнес процесс. я не понимаю что такое наследование. может тупой я, конечно, но на мой взгляд - это классификация, которую категорически нельзя закладывать в модель БД, ибо классифицировать любые сущности можно много много раз и по разному. пример какой нить практический приведите, попробую опровергнуть :) может вдруг соглашусь...

что вы всё лукавого какого то упоминаете. Знакомый ваш?
"ибо классифицировать любые сущности можно много много раз и по разному." ух ты! это говорит только о вашем умении классифицировать. ;)
18 ноя 04, 13:37    [1116744]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Извиняюсь, пропустил Ваши соображения о пользовательских отчетах и и "покрытии" реляционной схемой множества объектных схем.
Здесь Вы в завуалированной форме повторяете высказывания сторонников "реляционной" технологии:

1) кортежи отношений не представляют никаких сущностей, и никаких связей между сущностями;
2) реляционная технология позволяет "соединять таблицы на лету" (не по ключам).

Должен Вас огорчить: эти "идеи" не имеют никакого отношения к действительности. Вообще. Никакого.

Чем "лучше спроектирована" (как Вы выразились) "реляционная" база данных, тем меньше у пользователя шансов получить пользовательский отчет.
Чем "лучше спроектирована" объектная база данных, тем больше у пользователя шансов получить пользовательский отчет.
Только и всего.
18 ноя 04, 13:46    [1116785]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
с127 !

И перед Вами извиняюсь:

я - инженер-механик по специальности "летательные аппараты".

Ну что ? Стыдно стало, что человек с ТАКИМ образованием объясняет Вам теорию баз данных ? А Вы еще и понять не можете, хотя, судя по всему, являетесь дипломированным специалистом в этой области.
18 ноя 04, 13:49    [1116801]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32892

Привет, Андрей!
Ты пишешь:

Андрей
АЛ> я - инженер-механик по специальности "летательные аппараты".
АЛ> Ну что ? Стыдно стало, что человек с ТАКИМ образованием объясняет Вам теорию баз данных ?


10 баллов!
Беру в свою копилку.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

18 ноя 04, 13:54    [1116828]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович

реляционная технология позволяет "соединять таблицы на лету" (не по ключам).

Ага. Прямо в летательном аппарате по всей видимости.
18 ноя 04, 13:54    [1116830]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Андрей Леонидович

1) кортежи отношений не представляют никаких сущностей, и никаких связей между сущностями;
2) реляционная технология позволяет "соединять таблицы на лету" (не по ключам).

Должен Вас огорчить: эти "идеи" не имеют никакого отношения к действительности. Вообще. Никакого.

1) Кортежи отношений представляют собой высказывания формальной логики. Само отношение суть предикат. Если на место свободных переменных (атрибутов) подставить некоторые значения и вычислить, этот предикат даст значение "ИСТИНА". Собственно это и есть кортеж - вычисленный предикат со значением "ИСТИНА". Это действительно не имеет никакого отношения к действительности. Одна сплошная мат.логика.
2) Позволяет. Пример привести?
18 ноя 04, 13:58    [1116852]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Andrey K
dimon_n2000

да, по поводу наследственности - тоже от лукавого. в природе наследуются только гены. еще имущество, но это бизнес процесс. я не понимаю что такое наследование. может тупой я, конечно, но на мой взгляд - это классификация, которую категорически нельзя закладывать в модель БД, ибо классифицировать любые сущности можно много много раз и по разному. пример какой нить практический приведите, попробую опровергнуть :) может вдруг соглашусь...

что вы всё лукавого какого то упоминаете. Знакомый ваш?
"ибо классифицировать любые сущности можно много много раз и по разному." ух ты! это говорит только о вашем умении классифицировать. ;)


как раз нет. умения классифицировать умается мне не у кого нет.
но я занимался этим вопросом...:) я не понял из вашего сообщения - вам что то надо классифицировать или ы так просто спросили

зы: про лукавого - да, знакомый.
18 ноя 04, 14:00    [1116865]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Павел Воронцов
Это действительно не имеет никакого отношения к действительности.

БРАВО! БРАВО! Ничего более глубокоинтелектуального я не слышал. БРАВО!
18 ноя 04, 14:05    [1116883]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Andrey K
dimon_n2000

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

Да желательно предусмотреть, все варианты возникновения конфликтов. Тупо переносить не нужно.

dimon_n2000

если так, то в каше такая же фигня.... никаких проблем. да еще к тому же можно вообще собственный сервер обмена написать. на том же М, кстати. На SQL наверное не напишешь. Токо на другом языке. Хорошо или плохо - каждый себе сам решит.

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

А как это реализовано в Cache?


в каше это реализовано настройками конфигурации. и естьмеханизм, позволяющий ставить свои фильтры. я вообще то сторонник централизованных систем, но люди до сих пор вынуждены из за отсутсвия или неоправданной дорогвизны каналов связи делать распределенные. видел такую систему на каше (ДУ РАО ЕЭС России) - работает по всей стране. там свой сервер обмена написали. но там и функциоанльность бедненькая, поэтому и написали. но пользоваться стандартными средствами каше все равно в их ситуации действительно было бы неудобно. не знаю, насколько бы это было бы удобно в МС СКУЛе...
18 ноя 04, 14:05    [1116885]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Andrey K
Павел Воронцов
Это действительно не имеет никакого отношения к действительности.

БРАВО! БРАВО! Ничего более глубокоинтелектуального я не слышал. БРАВО!
Спасибо, спасибо, это мой логический END :)
18 ноя 04, 14:10    [1116901]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
dimon_n2000

Мне кажется, что Вы противоречивы. Не хотите разбираться - зачем Вы тогда на этом форуме ?
И мне за державу обидно. Только я, например, работаю с М 15 лет. Теперь в Каше. То, что наваяно в качестве объектов имеет на мой взгляд ряд концептуальных существенных недостатков. Но есть и достоинства. Но пока недостатки перевешивают, поэтому я не использую объекты каше в разработках.


Как это можно понять? Объекты в Кэше праздно присутствуют с точки зрения моделей данных (т.е. к модели данных отношения не имеют, а поддерживают какое-то программирование с помощью объектов) или он поддерживает несколько моделей данных и среди них ООМД? А какие еще, если без объектов?
18 ноя 04, 14:20    [1116965]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
dimon_n2000

написали. но там и функциоанльность бедненькая, поэтому и написали. но пользоваться стандартными средствами каше все равно в их ситуации действительно было бы неудобно.

Вот именно. А какие есть стандартные средства? Репликация снимков думаю есть. Репликация транзакций поддерживается? А репликация слиянием? в стандартных средствах.

Павел Воронцов

Спасибо, спасибо, это мой логический END :)

Точно! Посмеяться над собой тоже нужно уметь. ;)
18 ноя 04, 14:22    [1116978]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
vadiminfo
dimon_n2000

Мне кажется, что Вы противоречивы. Не хотите разбираться - зачем Вы тогда на этом форуме ?
И мне за державу обидно. Только я, например, работаю с М 15 лет. Теперь в Каше. То, что наваяно в качестве объектов имеет на мой взгляд ряд концептуальных существенных недостатков. Но есть и достоинства. Но пока недостатки перевешивают, поэтому я не использую объекты каше в разработках.


Как это можно понять? Объекты в Кэше праздно присутствуют с точки зрения моделей данных (т.е. к модели данных отношения не имеют, а поддерживают какое-то программирование с помощью объектов) или он поддерживает несколько моделей данных и среди них ООМД? А какие еще, если без объектов?

каше есть в фундаменте - М. Это иерархическая модель. Ее здесь пытаються назвать почему то реляционной.
На это йиерархической модели построены две - реляционная (разумеется не до конца) и объектная в соответсвии с ODMG. Посколоьку две остальные - это надстройки, то кк следствие внутри них кишочки состят из иерархических составляющих. Но этого сверху не видно :)
не знаю - понятно объяснили или нет....
18 ноя 04, 15:06    [1117237]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Andrey K
dimon_n2000

написали. но там и функциоанльность бедненькая, поэтому и написали. но пользоваться стандартными средствами каше все равно в их ситуации действительно было бы неудобно.

Вот именно. А какие есть стандартные средства? Репликация снимков думаю есть. Репликация транзакций поддерживается? А репликация слиянием? в стандартных средствах.



я не очень понимаю термины "репликация снимков", "репликация слиянием".

репликация транзакций понимаю так, что если транзакция случилась на одном сервере, то она должна оказаться на другом. В каше это есть. Токо за целостность данных никто не ответит, кроме вас.
18 ноя 04, 15:08    [1117242]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
dimon_n2000
каше есть в фундаменте - М. Это иерархическая модель. Ее здесь пытаються назвать почему то реляционной.
На это йиерархической модели построены две - реляционная (разумеется не до конца) и объектная в соответсвии с ODMG. Посколоьку две остальные - это надстройки, то кк следствие внутри них кишочки состят из иерархических составляющих. Но этого сверху не видно :)
не знаю - понятно объяснили или нет....

Дайте я Вас расцелую! Наконец то нашелся человек, который прямо сказал - иерархическая модель! А то - постреляционная БД, ОО два раза!
18 ноя 04, 15:15    [1117271]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
мы, дятлы
Guest
Павел Воронцов
Дайте я Вас расцелую! Наконец то нашелся человек, который прямо сказал - иерархическая модель! А то - постреляционная БД, ОО два раза!

Не целуйтесь с ними! Они же на мампсе пишут! А как же вечные идеалы? Да они же вас обманут! Да у них же язык такой чтобы специально всех запутывать! Ни за что не продавайте вечные ценности, только купленный в микрософт скл сервер и только в автоматическом режиме без грязных рук этих умников может выполнить репликацию! Плодите скл сервера и больше репликаций хороших и разных! Да здравствует!
18 ноя 04, 15:27    [1117320]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Павел Воронцов
dimon_n2000
каше есть в фундаменте - М. Это иерархическая модель. Ее здесь пытаються назвать почему то реляционной.
На это йиерархической модели построены две - реляционная (разумеется не до конца) и объектная в соответсвии с ODMG. Посколоьку две остальные - это надстройки, то кк следствие внутри них кишочки состят из иерархических составляющих. Но этого сверху не видно :)
не знаю - понятно объяснили или нет....

Дайте я Вас расцелую! Наконец то нашелся человек, который прямо сказал - иерархическая модель! А то - постреляционная БД, ОО два раза!


надеюсь, у Вас нет замашек известного Леонида Ильича...

постреляционная - маркетинг. в корень смотреть надо. а там - иерархическая. причем логические деревья храняться в Б деревьях, ибо это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность. Скорость доступа - логарифм, поэтому чем больше размер базы, тем стабильней становиться время доступа. такого нет пи при одном другом способе хранения.
РСУБД вынуждены хранить данные несколькими способами, поскольку изначально реляц модель предполагает отсутствие ключа, а следовательно отсутсвие идентификации записи. а раз нет идентфикации, то и обращаться можно токо к куче. чего и наблюдаем в оракл, например. как токо идентфикация пояляется (индексы например), то и хранить тут же предлагается в Б дереве, ибо оно оптимально. токо в оракле помоему и оно как то не очень здорово сделано. следствие - реализация всх технологий напрямую зависит от теории. а забота о реализации всех этих технологий в конечном счете ложиться на наши с вами кошельки.... дорого поэтому все, что делать дофига приходится. но физ способ хранения, разумееется всего лишь один из аспектов реализации какой либо модели. надо еще о надежности побеспокоиться, о масштабируемости. во интерсистемз взяла з аоснову то, что наработано годами и проверено и поверх наложила объекты и скуль (который всю жизть в мампсе был, кстати), и все это в красивый целофановый пакетик. это ж коммерция. и все это понятно.
свое мнение сказал.
18 ноя 04, 15:34    [1117343]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
dimon_n2000

я не очень понимаю термины "репликация снимков", "репликация слиянием".

репликация транзакций понимаю так, что если транзакция случилась на одном сервере, то она должна оказаться на другом. В каше это есть. Токо за целостность данных никто не ответит, кроме вас.

Понятно. Вопросов больше не имею. Дальнейшее обсуждение темы становится скушным.
18 ноя 04, 15:45    [1117393]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Прикольно....

У темы ОО а также у кашеедов бывают два обострения - весеннее и осеннее. Это - очередное осеннее обострение..... Типа как у шизофрении, только ИМХО здесь причина гораздо более прозаична - на улице темно и слякотно, пиво уже надоело ....(что вы, что вы, ну нет, ну я понимаю, что пиво надоестьне может...... но надо же перерывы делать)..... а тут можно лясы поточить, поразвлечся децл....
18 ноя 04, 15:59    [1117477]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
U-gene
Прикольно....

У темы ОО а также у кашеедов бывают два обострения - весеннее и осеннее. Это - очередное осеннее обострение..... Типа как у шизофрении, только ИМХО здесь причина гораздо более прозаична - на улице темно и слякотно, пиво уже надоело ....(что вы, что вы, ну нет, ну я понимаю, что пиво надоестьне может...... но надо же перерывы делать)..... а тут можно лясы поточить, поразвлечся децл....


вы сами то к докторам ходили ?
18 ноя 04, 16:06    [1117508]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 dimon_n2000



>>постреляционная - маркетинг. в корень смотреть надо. а там - иерархическая.

Ну наконец-то !!! Хоть один честно признался, иерархическая концепция у Каше :)


>>причем логические деревья храняться в Б деревьях, ибо это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность.

Шутите ?! Отнюдь не самый ! А если данные быстро меняются (вставляются, добавляются, изменяются) Б-дерево очень-очень быстро перестаёт быть сбалансированным или вовсе вырождается в связный список. Потому при любых изменениях данных нужно автоматически балансировать Б дерево (RBдеревом и вращением вершин) а это всё минус производительность. Кроме того обеспечение корректных изменений такого дерева в многопользовательской среде чревато массой трудностей (например блокирование всего дерева и т.п.).


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

Это смотря что понимать под "доступом". Если вы можете выделить атрибут объекта для которого хотите выстраивать дерево, то да есть смысл связываться с балансировкой и согласованностью, а если таких атрибутов несколько ? Например цена,артикул,дата и любой из них или любая их комбинация может понадобиться для поиска, группировок, сортировок, агрегатных функций и т.п. Тогда хранение в виде дерева представляется совсем невыгодным.

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

Вовсе не поэтому :) Вы думаете в Oracle и в IBM дяди глупее нас с вами ?
См. предыдущий пункт. Если данные представляют из себя пары (я намеренно избегаю термина кортеж, ибо может появиться коллега ЧАЛ и я могу надорваться от смеха) ключ-значение и изменений этих данных будет немного или не будет совсем пожалуйте index-oriented таблица, если значений несколько пожалуйте heap и индексы для нужных атрибутов (те же Btree).


>>чего и наблюдаем в оракл, например. как токо идентфикация пояляется (индексы например), то и хранить тут же предлагается в Б дереве, ибо оно оптимально.

Не всегда оно оптимально. Если таблица постоянно меняется, то лучше не надо в Btree её хранить :)

>>токо в оракле помоему и оно как то не очень здорово сделано. следствие - реализация всх технологий напрямую зависит от теории.


Ну вот дятлам например на теорию начхать :) Я знаю ещё много таких "marked-based victims" (классное определение, спасибо Павлу Воронцову).
18 ноя 04, 16:08    [1117520]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Andreww
2 dimon_n2000



>>постреляционная - маркетинг. в корень смотреть надо. а там - иерархическая.

Ну наконец-то !!! Хоть один честно признался, иерархическая концепция у Каше :)


>>причем логические деревья храняться в Б деревьях, ибо это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность.

Шутите ?! Отнюдь не самый ! А если данные быстро меняются (вставляются, добавляются, изменяются) Б-дерево очень-очень быстро перестаёт быть сбалансированным или вовсе вырождается в связный список. Потому при любых изменениях данных нужно автоматически балансировать Б дерево (RBдеревом и вращением вершин) а это всё минус производительность. Кроме того обеспечение корректных изменений такого дерева в многопользовательской среде чревато массой трудностей (например блокирование всего дерева и т.п.).


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

Это смотря что понимать под "доступом". Если вы можете выделить атрибут объекта для которого хотите выстраивать дерево, то да есть смысл связываться с балансировкой и согласованностью, а если таких атрибутов несколько ? Например цена,артикул,дата и любой из них или любая их комбинация может понадобиться для поиска, группировок, сортировок, агрегатных функций и т.п. Тогда хранение в виде дерева представляется совсем невыгодным.

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

Вовсе не поэтому :) Вы думаете в Oracle и в IBM дяди глупее нас с вами ?
См. предыдущий пункт. Если данные представляют из себя пары (я намеренно избегаю термина кортеж, ибо может появиться коллега ЧАЛ и я могу надорваться от смеха) ключ-значение и изменений этих данных будет немного или не будет совсем пожалуйте index-oriented таблица, если значений несколько пожалуйте heap и индексы для нужных атрибутов (те же Btree).


>>чего и наблюдаем в оракл, например. как токо идентфикация пояляется (индексы например), то и хранить тут же предлагается в Б дереве, ибо оно оптимально.

Не всегда оно оптимально. Если таблица постоянно меняется, то лучше не надо в Btree её хранить :)

>>токо в оракле помоему и оно как то не очень здорово сделано. следствие - реализация всх технологий напрямую зависит от теории.


Ну вот дятлам например на теорию начхать :) Я знаю ещё много таких "marked-based victims" (классное определение, спасибо Павлу Воронцову).


да, сложновато объяснять в письменном виде. вы вообще про что то другое говорите.....
во первых я не шучу. про реализхованный во всех М системах физический способ хранения в виде Б дерева я знаю все. Это не М системы, разумеется придумали. Они его все используют. И там нет никаких сложностей, о которых вы пытались чего то написать. Производительность - железно логарифм и в никакой список он не выраждается. скорость доступа - количство уровней блоков указателей. в каше, например, при размере логического дерва в миллион записей нужно с диска поднимать всегда три блока не зависимо от того, сколько само дерево будет занимать. тут вам надо почитать Паскаля, который алгоритм Б дерева описывает.

насчет умных дядек и нас с вами. я лично себя глупым не считаю (хоть и не скромно звучит). других людей я так же глупыми не считаю. у каждого - свой мир. и мировосприятие разное. если у вас нет уважения к самому себе - вы можете себя называть глупым или глупее чем дядьки в айбим. меня туда не причисляйте, пжлста.
я еще раз повторю, что я имел в виду. в РСУБД ВЫНУЖДЕНЫ реализовывать различные способы физической организации данных вследсстивии положений ТЕОРИИ реляционной модели, в которой идентификация сущностей МОЖЕТ отсутсвовать. Конечно, же в большиснстве случаев она присутсвует, но иногда может и отсутсвовать, поэтому и нужно реализовать как то работу с неидентфицируеыми данными. токо и всего.

насчет более оптимального способа хранения - приведите приммер другого способа, который вам гаратирует высокую и детерминированную скорость доступа и высокую эффективность дискового заполнения. желательно со ссылкой, где это можно почитать.
18 ноя 04, 16:30    [1117661]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
мы, дятлы
Guest
Andreww
Вы думаете в Oracle и в IBM дяди глупее нас с вами?

Даже не смейте так думать!
Там не дяди, там БОГИ!
И вам надлежит поступать только так, как они повелят!
Ибо sql!
18 ноя 04, 16:39    [1117724]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
dimon_n2000
в РСУБД ВЫНУЖДЕНЫ реализовывать различные способы физической организации данных вследсстивии положений ТЕОРИИ реляционной модели, в которой идентификация сущностей МОЖЕТ отсутсвовать.

Вот тут Вы, батенька, ошибаетесь. Это в SQL идентификация МОЖЕТ отсутствовать. А в РМД такого быть не может в принципе.

Б-деревья могут вырождаться. Почитайте Паскаля. А вот как М-системы достигают всегда уравновешенного дерева - это интересно, тут поподробней пожалуйста.
18 ноя 04, 16:41    [1117735]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Так. Сейчас придёт Андрей Леонидович и снова начнёт пояснять, что потенциальный ключ не есть идентификатор. Я пошёл домой.
18 ноя 04, 16:43    [1117738]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить