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

Откуда: Томск
Сообщений: 1027
okdoky
mir
Дайте чёткое определение "колоночной" СУБД. Скажем, Sybase IQ -- колоночная СУБД?
Опять Вас на четкие определения потянуло.
Да, люблю определённость в разговоре. Есть мнение, не я один. Слишком часто люди прячут мутность мысли за мутностью слов. Не зря говорят: кто ясно мыслит, тот ясно излагает.
okdoky
Под "четкими" Вы конечно понимаете "реляционные"?
Не надо за меня додумывать. Я вообще не понимаю, что такое "реляционные" определения в абстрактном смысле. Ладно, если вы не способны дать чёткие, дайте хоть какие-нибудь. Дайте хоть микроскопическую возможность понять, о чём вы толкуете: о логическом уровне или уровне реализации.
okdoky
Давайте говорить в терминах колонок и таблиц. Они не требуют определений, но понятны всем, надеюсь и Вам.
Да у вас память слабовата. Вы же участвовали в теме, где мы рассматривали в числе прочего зыбкость понятия «таблицы». Я приводил в пример не менее четырех популярных смыслов слова «таблица». И после этого вы снова заявляете, что эти термины «не требуют определений, но понятны всем»? Вы безнадёжны.
okdoky
mir
okdoky

SQL
select A from R1, R2 where R1.B = R2.B and R2.C = c1
Zigzag
= A(B(C:c1))
Вообще неясно, какая связь между первым и вторым текстами, кроме одинаковых букв A, B, C. В первом случае эти буквы -- имен атрибутов отношений R1, R2. Во втором -- неизвестно что.
В первом и во втором случае A,B,C это имена колонок. Как Вам еще проще объяснить, не знаю.
Имена колонок чего, простите? А если в базе 100 отношений, в который есть такие атрибуты? Откуда в вашем выражении СУБД узнает, к каким отношениям относятся эти имена? Мне правда интересно.
17 сен 07, 10:07    [4675535]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ЧАЛ-овек
Ну можно другие названия выбрать, например, норма и ко-норма или сумма и произведение. Какая разница? Важны их формальные свойства. Важно что есть два базовых способа слепить что-то более сложное из более простого. Часто разные науки изучают одно и то же разными способами. Например, есть булева алгебра, есть исчисление высказываний и есть решетки. Почему там одно и то же разными словами описывают? Потому что исходят из разных традиций.

А зачем чего-то выбирать, когда уже до Вас все давно выбрано, и называется по-другому. Чтобы на ровном месте все запутать?
Кстати, Вы так и не ответели на вопрос mir'а насчет того, почему отношение есть дизъюнкция, ну и заодно уж для меня ответьте почему кортеж есть конъюнкция?
17 сен 07, 10:07    [4675536]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Локшин Марк
Кстати, Вы так и не ответели на вопрос mir'а насчет того, почему отношение есть дизъюнкция, ну и заодно уж для меня ответьте почему кортеж есть конъюнкция?
И для меня тоже. Я поторопился и с кортежом, тут тоже непонятки. Соединяете логическими операциями произвольные (не логические) значения, что бы это значило?
17 сен 07, 10:10    [4675556]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
mir
Локшин Марк
Кстати, Вы так и не ответели на вопрос mir'а насчет того, почему отношение есть дизъюнкция, ну и заодно уж для меня ответьте почему кортеж есть конъюнкция?
И для меня тоже. Я поторопился и с кортежом, тут тоже непонятки. Соединяете логическими операциями произвольные (не логические) значения, что бы это значило?
Видимо, это несколько неформальная констатация того факта, что существование одной строки в отношении никак не влияет (без дополнительных ограничений) на наличие других строк.
В то же время по определению невозможно существование одного лишь элемента n-кортежа (n>1) без других.
17 сен 07, 11:40    [4676143]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
okdoky
В первом и во втором случае A,B,C это имена колонок. Как Вам еще проще объяснить, не знаю.


Если это имена доменов (или Базисных множеств в теории структур), то все нормально. Домены как множества могут участвовать во многих отношениях и иметь в них свои проекции, к которым можно было бы обращаться по имени домена (а не по имени атрибута в отношении), если бы не одно (и еще несколько) «но».
Имеется целый класс структур, использующих бинарные, n-арные и более сложные отношения (с внутренней структурой элементов отношения, например, в спецификации абстрактного процесса будет множество объектов входа и множество объектов выхода).
То есть домен используется в ОДНОМ отношении в РАЗНЫХ ролях. Например, отношение подчинения между людьми в организациях с двумя атрибутами: начальник, подчиненный.

Чтобы целостно разрулить такую ситуацию, то придется или нумеровать вхождения домена в отношение или вводить промежуточные классы, отношения (что даже в там простейшем случае крайне неудобно: в данном случае изначально придется вводить два подмножества домена Сотрудники, R2, R3, Множество всех начальников, Множество всех подчиненных, а уже из них делать Отношение починения. А потом заставлять бедного пользователей вводить 3 отношения (а с фига ли ему знать заранее, кто там начальник, кто подчиненный, пока он отношение не задал).

Этот пост не столько okdoky, сколько Сахавату, который заблуждается насчет достойности введения множества Типов и отношений входимости на них (или запретов на них, что все равно, но еще хуже).

А вот полноценные отношения с отношением вхождения типов (ссылочная целостность) решают эту проблему.
Возможно, я заблуждаюсь, так как не владею техническим уровнем (физической реализацией СУБД и языков), но проблема (приводящая к желанию ввести метауровень для расширяемости и управления в коде) заключается в том, что языковые средства заточены на оперирование реляционными структурами, а связи по вхождению в отношения (доменов и производных типов) хранятся в СУБД, и с ними нет языка работы прямого (в тех же запросах).
Так вынести просто эти связи в метамодель, да и дело с концом.

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

Сахават, другой проблемой является твое приписывание свойств типам произвольным образом. Это вообще кошмар в смысле целостности. Сам подумай, что будет, если окажется, что два типа (с разными именами, идентификацией) имеют полностью одинаковые атрибуты.
Фактические, свойства у тебя, - это отдельный выделенный подкласс доменов. И с ними что хочешь может быть, любые зависимости и т.д. То есть противоречие в модели очень легко может появиться бесконтрольно.
С моей точки зрения, всю системную структуру надо задавать реляционно+выносить в метаурововень все отношения и вхождение классов (для автоуправления ими, расширения – введение новых классов, расширение связей, снятия видимости (псевдосужения), а на дополнительные пользовательские свойства (которые считай, что объектные) накладывать жесткие ограничения. Будет два уровня расширения – через метамодель (любое) и ограниченное простое через пользовательские свойства.
Получается как бы 3 уровня:
- ООП метамодель
- РМодель
- О-расширение.
Таково мое мнение.
17 сен 07, 13:17    [4676846]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Простите, что лезу, просто пара комментариев.
всем сестрам по серьгам
Домены как множества могут участвовать во многих отношениях […] если бы не одно (и еще несколько) «но». […] домен используется в ОДНОМ отношении в РАЗНЫХ ролях.
Чисто исторически, с этого начинал Кодд в своей эпохальной статье "A Relational Model of Data for Large Shared Data Banks". Он в ней использовал только домены (атрибутов не было), а для различения одного и того же домена ввел термин «роль» домена в отношении. Поэтом эта роль и стала называться атрибутом. Различение доменов через нумерацию он отмёл как непрактичную (неудобную для человека и т.д.).
всем сестрам по серьгам
Возможно, я заблуждаюсь […], но проблема (приводящая к желанию ввести метауровень для расширяемости и управления в коде) заключается в том, что языковые средства заточены на оперирование реляционными структурами, а связи по вхождению в отношения (доменов и производных типов) хранятся в СУБД, и с ними нет языка работы прямого (в тех же запросах).
Во всех РСУБД метаданные хранятся реляционным способом, и с ними можно работать теми же операторами SQL, что и с обычными данными.
17 сен 07, 13:49    [4677059]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
mir
Чисто исторически, с этого начинал Кодд в своей эпохальной статье "A Relational Model of Data for Large Shared Data Banks". Он в ней использовал только домены (атрибутов не было), а для различения одного и того же домена ввел термин «роль» домена в отношении. Поэтом эта роль и стала называться атрибутом. Различение доменов через нумерацию он отмёл как непрактичную (неудобную для человека и т.д.).


Чисто исторически это было придумано за 50 лет до Кодда.
Но речь не о том.

В том-то и фишка, что нужно и то и другое – и нумерация и имена ролей (атрибуты), либо двойные имена: Начальник/Сотрудник и Подчиненный/Сотрудник.
Из-за того и говорят о «потере семантики» и т.д., за это борьба на мой взгляд.
Оставив только атрибуты мы теряем, что это подмножества одного и того же домена (или необязательно, домена, может, другого класса, отношения – тем более теряем, тут просто атрибутами не обойтись).

Речь о том, что, допустим, домен участвует во многих отношениях в разных ролях. Мне надо собрать для задачи терм по нескольким отношения. Если моя метамодель знает, в каких отношениях участвует интересующий домен, то я могу не указывать отношения, а сказать «все» или «все такие, что».
И все триггеры автоматом привязать куда надо, и т.д.
То есть либо двойные имена либо нумерация вхождения в отношение.

mir
Во всех РСУБД метаданные хранятся реляционным способом, и с ними можно работать теми же операторами SQL, что и с обычными данными.


Извиняюсь за неточность выражения. Речь о (возможной?) недостаточности средств по управлению вхождением доменов в разные отношения, в разных ролях. Дальше возникают «деревья вхождений». Об этом знает программист, пишущий запрос, об этом отдельно знает СУБД (хранящая ссылочную целостность). О «деревьях вхождения» как бы не знает никто (то есть программист, зная, должен запросить СУБД о парах, их них самому построить «дерево» и задать запрос). А программисту об этом можно не знать, если бы запросы строились с использованием этого знания СУБД. Потому и хочется это вынести в метауровень.
Наверно опять непонятно выражаюсь :-(
17 сен 07, 14:33    [4677374]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
всем сестрам по серьгам
Чисто исторически это было придумано за 50 лет до Кодда.
Но речь не о том.


Именно за 50 ??? Источник не процитируете ?
17 сен 07, 15:01    [4677571]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
блин, неужели вы всё это читаете?..
17 сен 07, 15:31    [4677826]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
всем сестрам по серьгам
В том-то и фишка, что нужно и то и другое – и нумерация и имена ролей (атрибуты), либо двойные имена: Начальник/Сотрудник и Подчиненный/Сотрудник.
Кому нужно? И нужно ли вообще?
всем сестрам по серьгам
Из-за того и говорят о «потере семантики» и т.д., за это борьба на мой взгляд.
Нет никакой потери. Имя атрибута есть. Имя домена есть. И то и другое можно узнать (связать) из метаданных.
всем сестрам по серьгам
Оставив только атрибуты мы теряем, что это подмножества одного и того же домена (или необязательно, домена, может, другого класса, отношения – тем более теряем, тут просто атрибутами не обойтись).
Ничего не теряем (см. предыдущий комментарий).
всем сестрам по серьгам
Речь о том, что, допустим, домен участвует во многих отношениях в разных ролях. Мне надо собрать для задачи терм по нескольким отношения. Если моя метамодель знает, в каких отношениях участвует интересующий домен, то я могу не указывать отношения, а сказать «все» или «все такие, что». И все триггеры автоматом привязать куда надо, и т.д.
Задача выглядит надуманной. Приведите пару реальных примеров из практики, требующих постоянно узнавать, в какие отношения входит домен. Далее, если такая задача всё же возникнет, я могу написать запрос, используя метаданные и динамический SQL, который сделает всё, что надо. И все триггеры привязать куда надо.
всем сестрам по серьгам
Речь о (возможной?) недостаточности средств по управлению вхождением доменов в разные отношения, в разных ролях.
Ну, средства есть (метаданные + динамический SQL). Да, они могут быть не слишком удобными. Но для активной их поддержки нужно обосновать, что это задача вообще актуальна. Есть подозрение, что проблема высосана всё же из пальца.
17 сен 07, 15:36    [4677867]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
Gluk (Kazan)
Именно за 50 ??? Источник не процитируете ?


Мне бодаться по данному вопросу не интересно, на продолжение отвечать не буду. Так как авторство все равно не мое :-).
Я родоначальниками подхода считаю теорию структур Бурбаки, 1936 год, кажется, первые публикации. У нас вышли уже после нескольких переработок в разделе 1 тома Бурбаки Н. Теория множеств. Прикладными вопросами они не занимались, и не ищите, но системы взаимосвязанных отношений на ступенях из базисных множеств (доменов) введены там, называются только по другому.
У нас прикладными вопросами реализации теории структур начали заниматься с начала 70-х, математик Персиц Давид Борисович и системщик Никаноров Спартак Петрович, а также целый ряд других товарищей.
Так что процитировать проблематично. Но можно, если задаться целью.

Вот выдерка по Персицу, обцитироваться:

Никаноров С. П., Персиц Д. Б. Метод формального проектирования целостных систем организационного управления // Междунар. симп. по проблемам организационного управления и иерархическим системам: Сб. реф. докл., Баку, сентябрь – октябрь 1971 г. / ИПУ АН СССР. – М., 1972. – Ч. 1. – С. 52-56.
Никаноров С. П., Персиц Д. Б. О разработке метода формального проектирования целостных систем организационного управления // Типизация и автоматизация процессов проектирования АСУ: Материалы Всесоюзн. семинара по типизации и автоматизации проектирования АСУ. – Душанбе: Дониш, 1972. – С. 277-292.
Никаноров С. П., Персиц Д. Б. Метод проектирования целостных систем организационного управления // Сб. тез. докл. XXXII науч.-техн. конф., 28-30 марта 1973 г. / МИСИ им. В. В. Куйбышева. – М., 1973. – С. 14-15.
Никаноров С. П., Персиц Д. Б. Некоторые результаты разработки методов автоматизации проектирования АСУ в строительстве // Автоматизация проектирования систем организации и управления строительством: Сб. тез. докл. и сообщ. Всесоюз. науч. конф. / ЦНИПИАСС Госстроя СССР. – М., 1973. – С. 25-30.
Никаноров С. П., Персиц Д. Б. Об одном подходе к автоматизации проектирования систем организационного управления // Прикладные проблемы теории систем и системотехники: Материалы семинара, март 1973 г. / МДНТП им. Ф. Э. Дзержинского. – М., 1973. – С. 39-46.
Пономарев Ю. В., Никаноров С. П., Персиц Д. Б. Планирование и управление при поточно-стадийной технологии строительства АЭС // Энергетическое строительство. – М.: Энергия, 1973. – № 10 (148). – С. 78-82.
Никаноров С. П., Персиц Д. Б. Разработка математического обеспечения машинного проектирования целостных систем организационного управления // Разработка систем математического обеспечения автоматизированных систем управления: Сб. тез. докл. / ЦНИИТЭИ приборостроения. – М., 1973. – С. 82-83.
Никаноров С. П., Персиц Д. Б. Формальное проектирование целостных систем управления - развитие идеи конструирования организаций // Науч.-техн. конф. по структурам управления промышленными комплексами: Сб. тез. докл., Таллин, 22-23 октября 1973 г. – Таллин, 1973. – С. 10-14.
Никаноров С. П., Персиц Д. Б. Проектирование целостных систем организационного управления // Внедрение в строительство электронно-вычислительной техники и создание автоматизированной системы управления (ОАСУ "Энергия") в энергетическом строительстве: Сб. тез. докл. отрасл. конф. Минэнерго СССР / Информэнерго. – М., 1974. – С. 65-68.
Егоров Б. Б., Закс Б. А., Никаноров С. П., Персиц Д. Б., Портнов Г. Я. Основные элементы автоматизированной системы проектирования систем организационного управления // Проблемы автоматизации управления строительством. Проектирование организаций: Тр. / ЦНИПИАСС Госстроя СССР. – М., 1977. – Вып. 17. – С. 30-42.
Никаноров С. П., Персиц Д. Б. Об одном направлении в развитии теории систем и его значении для приложений // Вопросы кибернетики / АН СССР – М., 1977. – Вып. 32. – С. 74-89.
Никаноров С. П., Персиц Д. Б., Худояров В. В. Проектирование систем организационного управления с помощью АСП СОУ // Проблемы автоматизации управления строительством. Проектирование организаций: Тр. / ЦНИПИАСС Госстроя СССР. – М., 1977. – Вып. 17. – С. 43-54.
Персиц Д. Б., Савелов Е. В., Тищенко А. В. Теоретические основы построения автоматизированной системы проектирования систем организационного управления // Проблемы автоматизации управления строительством. Проектирование организаций: Тр. / ЦНИПИАСС Госстроя СССР. – М., 1977. – Вып. 17. – С. 20-29.
Аламдарова М. Р., Егоров Б. Б., Комарова М. И., Малиновская Е. В., Никаноров С. П., Никитина Н. К., Персиц Д. Б., Солнцев С. В., Тищенко А. В. Способ представления структуры данных общесистемного информационного обеспечения комплекса АСУ строительного министерства / ЦНИПИАСС Госстроя СССР. – М., 1980. – 12 с. – Деп. в ЦИНИС Госстроя СССР 02.04.80, № 1893. – БУДР. 1980. – Вып. 4.
Никитина Н. К., Персиц Д. Б., Солнцев С. В., Тищенко А. В. Теоретические основы и математические средства описания структуры данных в техническом проекте общесистемного информационного обеспечения комплекса АСУ министерства. – М., 1980. – Деп. в ЦИНИС Госстроя СССР, 1980, № 1890. – БУДР. 1980. – Вып. 4.
Персиц Д. Б., Савелов Е. В., Тищенко А. В. Индуцированная фактор-структура на ступени и ее применение // Проблемы совершенствования организации управления энергетического строительства: Сб. науч. тр. / Всесоюзный институт по проектированию организации энергетического строительства "Оргэнергострой" Минэнерго СССР. – М., 1981. – С. 22-30.

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

http://www.supir.ru/j8s4.html
17 сен 07, 15:41    [4677910]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
mir
Да, они могут быть не слишком удобными. Но для активной их поддержки нужно обосновать, что это задача вообще актуальна. Есть подозрение, что проблема высосана всё же из пальца.


Ваше мнение понятно. Вопрос за примерами, я подумаю. Те, кто затеял это обсуждение (адепты объектности и др.) должны владеть примерами.
17 сен 07, 15:45    [4677947]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
всем сестрам по серьгам
Gluk (Kazan)
Именно за 50 ??? Источник не процитируете ?

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


Ok позиция понятна
17 сен 07, 16:04    [4678108]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
всем сестрам по серьгам
У нас прикладными вопросами реализации теории структур начали заниматься с начала 70-х, математик Персиц Давид Борисович и системщик Никаноров Спартак Петрович, а также целый ряд других товарищей.
Так что процитировать проблематично. Но можно, если задаться целью.

Вот выдерка по Персицу, обцитироваться:
Это действительно интересно, но с точки зрения приоритета всё же не раньше Кодда.

всем сестрам по серьгам
Вот последняя статейка Никанорова. О том, что, косвенно, реляционных представлений мало для описания сложных предметных областей, нужно расширение используемых структур.http://www.supir.ru/j8s4.html
Прочитал статью. Не нашел там того, что вы сказали. Он все о графах.
17 сен 07, 16:11    [4678172]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
mir
Прочитал статью. Не нашел там того, что вы сказали. Он все о графах.


Это косвенный аргумент, ни на что больше не претендует.
Никаноров ни реляционными представлениями, ни ООП, ни даже теорий графов не пользуется. Потому и было сказано, что «косвенно», то есть это моя интерпретация цели его текста, я лично знаю его позицию и могу интерпретировать. Речь о гиперграфах и других структурах, которые используются в прикладном проектировании для целей задания классов (в смысле ООП) со сложной структурой.

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

Это моя позиция. То, что Вы ее не разделяете, Ваше право. Не имею цели кого-то убеждать (кроме Сахавата, у которого я полузаказчик и мне нужна правильная структура).
А примеров полно, только что-то из головы выпали :-) Пусть господа помогут, тот же okdoky привел пример: два отношения связаны по домену. И так известно, что связаны, значит можно опустить указания на источник (но там другая проблема, нет ни порядка, ни атрибутов, из-за чего и пришлось встрять). Получается, что сначала мы в СУБД ссылочную целостность задаем, а потом еще раз ее же запросах поддерживаем, в тригерах, .... А зачем масло масленное?

Меня больше интересует, дошло ли что-то до целевых оппонентов :-)
17 сен 07, 16:55    [4678504]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
всем сестрам по серьгам
А зачем масло масленное?


затем, что можно связать ПО ДРУГОМУ, а СУБД с искусственным интеллектом еще не изобрели


P.S. Вы можете не разделять МОЮ точку зрения
17 сен 07, 17:08    [4678607]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
всем сестрам по серьгам
Об чем тут все и талдычат.

Да талдычат о другом: для работы с объектами нужна ОСУБД (а про РСУБД можно зыбыть). Но если вам нужна формальная модель предметной области и с этой моделью вы собираетесь работать, то нужна РСУБД. Т.е. определитесь, что вам нужно, и, соответсвенно, выбирайте инструмент для работы.
17 сен 07, 17:26    [4678732]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
Gluk (Kazan)
всем сестрам по серьгам
А зачем масло масленное?


затем, что можно связать ПО ДРУГОМУ, а СУБД с искусственным интеллектом еще не изобрели


Речь была об однозначных случаях, когда не надо ни о чем спрашивать, тут вообще никакого интеллекта не надо.
А если есть многообразие первичных связей (задано), то перечислить многообразие вариантов связей не проблема (как классов запросов, сами они, конечно же, не перечислимы)
Для того, чтобы знать, что это один домен, один класс, одна система классов, не надо естественного интеллекта, искусственного способа сравнения имен, атрибутов, структур в простейшем случае предостаточно. Но этого нет :-(, Вы правы.
17 сен 07, 17:46    [4678882]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
мод
всем сестрам по серьгам
Об чем тут все и талдычат.

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


Так я и говорю, что мне нужна и та и другая одновременно. И никакой проблемы соединения я не вижу. Мне нужна формальная объектно-реляционная модель предметной области, однозначно отображаемая в РСУБД для удобства оперирования. В каждый момент (между изменениями классов и объектов) она отображаема, так что какие проблемы (проблемы избыточности меня мало волнуют, если это целостная избыточность).
17 сен 07, 17:48    [4678899]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ЧАЛ-овек
Guest
мод
всем сестрам по серьгам
Об чем тут все и талдычат.

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

Нет, нет такой альтернативы. Формальная модель предметной области не одно и то же, что и модель данных. Это весьма разные вещи. Далее, ОСУБД нужна не для работы с объектами, а для работы с данными, точно так же как и РСУБД и др. СУБД. И эта направленность на данные их всех объединяет. А наличие того или иного числа формализмов, используемых для изучения моделей, это уже другой вопрос, который никак не влияет на суть моделирования данных.
17 сен 07, 17:52    [4678936]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
мод
всем сестрам по серьгам
Об чем тут все и талдычат.

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


Случай в моем "творчестве" уникальный. :)
"Полузаказчик" пытается контролировать структуру, алгоритмы и т.д.
Например, я не знаю какова структура предприятия.
Может это и топорно (но, учитывая, что изменения структуры будут относительно редки и данных маловато ) я ввел пользовательский шаблон в виде графа. Пользователь вводит элементы структуры (типа справочник) - холдинг, предприятие, склад, цех,... ну что ему надо и строит разрешающий (ограничительный) граф. Реальная структура строится с учетом этого графа, который, допустим, не дает возможности включить цех в склад (т.е., склад не может в себе (в подчинении??) содержать цех).
Взамен предлагается создать 10 пронумерованных записей (уровней) и разрешить всем нижним уровням войти во все верхние.

И в ход идут аргументы, что у меня нет целостности, и т.д.
17 сен 07, 17:58    [4678977]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ЧАЛО-овек
Guest
всем сестрам по серьгам
... Получается, что сначала мы в СУБД ссылочную целостность задаем, а потом еще раз ее же запросах поддерживаем, в тригерах, .... А зачем масло масленное?


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

На самом деле это самый большой прокол РМ. Просто то, что Вы называете ссылочной целостностью, на самом деле неправильно, поскольку ссылок в РМ нет. Это выдача желаемого за действительное. Причем это не только неправильный термин, а неправильно по существу, т.е. FK констрейнт плохо приспособлен для организации ссылочной целостности, точно так же как PK плохо подходят для организации ссылок. Но использование терминов как ссылочная целостность показывают просто чего большинство простых разработчиков хотят иметь. В результате получается, что народ пытается лепить горбатую РМ к стенке. Что из этого получается мы все знаем - ничего в лучшем случае.

P.S. Кстати, не пытайтесь влезать в дискуссии с mir, U-gene, Gluk и др. реляционной бRатвой. Это обычные форумные троли, которые убивают любую содержательную дискуссию. Они сидят в реляционном подвале и ничего вокруг не хотят видеть. Для них весь мир это отношения и кортежи, а до Кодда мира вообще не было :) Бывает и такое.
17 сен 07, 18:05    [4679034]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ЧАЛ-овек
Guest
всем сестрам по серьгам
Вот последняя статейка Никанорова. О том, что, косвенно, реляционных представлений мало для описания сложных предметных областей, нужно расширение используемых структур.

http://www.supir.ru/j8s4.html


Интересно, что в этой статье ребро это E(A, B) где A и B это могут быть тоже множества, а кратность это глубина вложенности вершин.

Но обычно под гипер-графом понимают другую структуру. А именно, одно ребро гипер-графа связывает (одновременно) множество вершин (в смысле ребро имеет много концов к одиночным вершинам. Т.е. ребро это E(a,b), а в гипер-графе ребро это E(a1,a2,...,an), где n это кратность ребра.

Интересно, действительно есть два определения и два подхода? Я знаю, что определение, основаное на кратности ребер (а не вложенности вершин) имеет содержательную теорию, а вот про определение, что в статье дано, ничего не читал.
17 сен 07, 18:10    [4679070]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ЧАЛ-овек
Guest
mir
всем сестрам по серьгам
Возможно, я заблуждаюсь […], но проблема (приводящая к желанию ввести метауровень для расширяемости и управления в коде) заключается в том, что языковые средства заточены на оперирование реляционными структурами, а связи по вхождению в отношения (доменов и производных типов) хранятся в СУБД, и с ними нет языка работы прямого (в тех же запросах).
Во всех РСУБД метаданные хранятся реляционным способом, и с ними можно работать теми же операторами SQL, что и с обычными данными.

Эти данные не являются частью РМ, а то, что их можно достать на SQL из системных таблиц не является определяющим, и также говорит о кривости модели. Другими словами, получается, что необходимость работы с мета-данными есть (раз открывают системные таблицы), а в модели для этого ничего нет.
17 сен 07, 18:14    [4679087]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ЧАЛ-овек
Guest
Gluk (Kazan)
всем сестрам по серьгам
Gluk (Kazan)
Именно за 50 ??? Источник не процитируете ?

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


Ok позиция понятна

Главное с умным видом помотать головой, услышав незнакомое слово :) Или типа Бурбаки за 5 быстренько прочитал. Это как mir за пару минут дает рецензии на статьи в стиле все вы дураки, а а Дейт все равно лучше.

Сразу вспоминается анекдот, который в перефразированном виде будет так звучать (надеюсь оригинал все знают):

В ООН встает представитель и задает вопрос:
- Какая самая плохая модель данных?
Тут же с места вскакивает mir или Глюк и обиженно кидает реплику:
- Ну и что? Зато реляционная модель на теории множеств основана.
17 сен 07, 18:23    [4679130]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить