Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 34 35 36 37 38 [39] 40 41 42 43 .. 51   вперед  Ctrl
 Re: Закат RDBMS?  [new]
Бред
Guest
shuklin
Бред
shuklin
Бред
Это же очевидно, что запрос не должен "портить" БД.

Данный тезис не совсем верен. Запрос может "не портить" схему БД, если это требуется в данном конкретном случае. Но в общем случае, например для поддержки legacy приложений в процессе выполнения запроса может возникнуть необходимость трансформировать схему.


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


Это к Вашему тезису о том, что запрос к БД должен сохранять схему БД. Я против слова "должен", т.к. это полезно, но не всегда. А про РМД я особо и не забочусь. Моя СУБД разработана на основе сетевой МД в том виде, в каком я ее (СМД) вижу. И схему БД при выполнении запросов я сохраняю: https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=471830&hl=


Еще раз подчеркну, что результатом запроса является удовлетворяющая запросу часть БД со всей присущей БД семантикой. Что касается представления результата и немодельной обработки (агрегирование и т.п.), то здесь фантазия безгранична. Так что, результат - "должен". А представление - это другое дело. А что Вы подразумеваете под "трансформацией схемы" я пока не понимаю.
16 дек 07, 23:00    [5055721]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
Бред
Вот это честно. Подвердили, что нечего сказать на: "Конечно, запрос должен возвращать информацию, а не данные. Именно это и происходит при использовании КОМД. И это принципиально невозможно при использовании РМД без соответствующих надстроек, о которых говорил Злой". Вы тупой и трусливый недоучка.

Зациклило окончательно? Похоже у ЧАЛа этого тупрого, трусливого, подлого полудурка (или как он там подписывался) и последняя извилина на заднице.


Герой! Окончательно подвердил, что обижен исключительно на собственные трусость и непрофессионализм. Нечего сказать на: "Конечно, запрос должен возвращать информацию, а не данные. Именно это и происходит при использовании КОМД. И это принципиально невозможно при использовании РМД без соответствующих надстроек, о которых говорил Злой". И обиделся.
16 дек 07, 23:02    [5055725]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

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

Еще раз подчеркну, что результатом запроса является удовлетворяющая запросу часть БД со всей присущей БД семантикой. Что касается представления результата и немодельной обработки (агрегирование и т.п.), то здесь фантазия безгранична.

С этим полностью ОК.

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


Допустим у нас есть некоторая БД, вернули результат в той же схеме, приложение довольно, все счастливы. Ну ок. Общие авации продолжались по этому поводу год. Потом изменились требования к приложению. Нужно менять схему БД. А по условиям эксплуатации невозможно сразу заменить все клиентские приложения на новые их версии. Нужно обеспечить обратную совместимость. Т.е. сформирвать некоторые view представляющие схему БД в старом виде для старого приложения, позволив работать с теми же данными ТОЙ ЖЕ ИДЕНТИЧНОСТИ новому приложению уже в новой схеме. Как будем решать эту задачу без трансформации схемы в процессе выполнения запроса?
16 дек 07, 23:08    [5055734]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
shuklin
Бред

Еще раз подчеркну, что результатом запроса является удовлетворяющая запросу часть БД со всей присущей БД семантикой. Что касается представления результата и немодельной обработки (агрегирование и т.п.), то здесь фантазия безгранична.

С этим полностью ОК.

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


Допустим у нас есть некоторая БД, вернули результат в той же схеме, приложение довольно, все счастливы. Ну ок. Общие авации продолжались по этому поводу год. Потом изменились требования к приложению. Нужно менять схему БД. А по условиям эксплуатации невозможно сразу заменить все клиентские приложения на новые их версии. Нужно обеспечить обратную совместимость. Т.е. сформирвать некоторые view представляющие схему БД в старом виде для старого приложения, позволив работать с теми же данными ТОЙ ЖЕ ИДЕНТИЧНОСТИ новому приложению уже в новой схеме. Как будем решать эту задачу без трансформации схемы в процессе выполнения запроса?


Я уже сказал как. Не программировать приложения. Это идеал, к которому я бы стремился. Изменилась схема (потому что в концептуальной модели не были учтены какие-то особенности предметной области изначально) - выполнил реструктуризацию метаданных и данных, и вперед.
16 дек 07, 23:15    [5055744]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

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

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

Это не техническое а политико-методологическое решение. Поэтому в технической дискуссии не катит. Что вы посоветуете делать, если на вашей модели некто (пусть даже и не столь квалифицированный разработчик как хотелось бы) соберет запрограммированное и скомпилированное приложение? Что делать с сложившимся фактом? А ведь если модель получит распространение, и не такие чудеса с ней будут вытворять. Итак, что делать технически для обеспечения работоспособности для конкретно приведенного примера? Если слить с темы - тоже ок, запишем этот момент в недостатки вашей модели и подхода.
16 дек 07, 23:26    [5055760]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бред
Нечего сказать на: "Конечно, запрос должен возвращать информацию, а не данные. Именно это и происходит при использовании КОМД. И это принципиально невозможно при использовании РМД без соответствующих надстроек, о которых говорил Злой".

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

Для новеньких.
ЧАЛ расчитывает, на то что он будет повторять. Оппонентам повторно ему отвечать надоест. Тада он скажет: "Нечего сказать". Раньше он сразу в таких говорил: "Раз молчат, значит мы пришли к выводу..." - о "крахе РМД" или "превосходстве ДОМД".
17 дек 07, 00:10    [5055823]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
наблюдатель и
Guest
http://www.izvestia.ru/special/article3111189/
уж и не знаю к чему это я?
17 дек 07, 00:24    [5055853]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
наблюдатель и
http://www.izvestia.ru/special/article3111189/
уж и не знаю к чему это я?

Об этом я не подумал. Пусть тада его пустят какой-нибудь семинар, а то доиграемся.
17 дек 07, 01:11    [5055918]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ModelR

как же так, дорогая редакция?

Более того, все запросы содержат на 90% одну и ту же инфу, поскольку таблицы связываются одинаково, поскольку это одна предметная область.
Верно, просто тьма кода содержит
where ... Y.x_id = X.id 
при объявленной связи
FK "xyFK1" Y.x_id ref X.id
Но даже в этом, казалось бы однозначно выигрышном для критики JOIN примере, есть нюансы.
ИМХО довольно практично то, что JOIN симметричен. Как следствие, например FULL OUTER JOIN кроме "FULL OUTER " ничем ситаксически не отличается от JOIN.
Используя же несимметричную запись навигационного типа
X.xyFK1.<Ydata>
Y.xyFK1.<Xdata>
придется FULLить ручками.

shuklin
Отказ от JOIN в явном виде и замена его оператором навигации - точкой "." можно считать очень полезным синтаксическим сахаром.

SCHEME DEPT[].1.EMP[NUM,NAME]
WHERE EMP[SAL]>20K AND DEPT[NUM]='D3'

Все отделы без сотрудников и сотрудники за штатом:
select dept.name, emp.mame
from dept full outer join emp on (dept.dept#=emp.dept#)
where dept.name is null or emp.name is null
как оно будет с сахаром?
17 дек 07, 10:58    [5056536]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
Меня прежде всего интересовало доказательство концепций.
В виде прототипа.
А не мудрствования.
Мудрствования здесь на форуме, и не здесь на формуме, уже много лет безрезультатно идут.
ЧАЛ, я не предлагал семинар изначально - посмотрите внимательно.
Я предлагал вам демонстрацию.
И только.
Вам есть что показать?
Нет - не надо.
Есть - милости просим.
17 дек 07, 12:35    [5057165]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
shuklin
pavelvp
Нет, и ещё раз нет. Не может у объекта быть много идентификаторов! Идентификатор - уникальное имя. Идентификатор должен идентифицировать, всегда и только всегда, только один объект и объект должен идентифицироваться только одним идентификатором. В противном случае ничего Вы им идентифицировать не сможете.

У объекта не просто может, а должно быть много разных идентификаторов. И мало того не просто для галочки должно, а это очень полезная на практике функциональность ООСУБД:
https://www.sql.ru/forum/actualthread.aspx?tid=310465


Господин Шуклин, ответьте на один простой вопрос: если объект имеет несколько "идентификаторов", то каким же, позвольте Вас спросить, образом вы этот объект идентифицируете? В одном месте сохранили один "идентификатор", в другом другой, в третьем третий. Итого, в трех разных местах, имеем три разных "идентификатора". Как же нам узнать, что это один и тот же объект?
Идентификатор не может иметь синонимов - это уже не будет идентификатор. Если есть есть синонимы - значит кто-то знает, что это синонимы. Т.е. только кто-то стоящий выше и обладающий этим знанием, настоящим индентификатором (true identifier), может их идентифицировать.

Цитата с приведенной Вами ссылки https://www.sql.ru/forum/actualthread.aspx?tid=310465
shuklin
В различных контекстах определяемых различными экземплярами объектов один и тот же идентификатор объекта NativeHandle может адресовать как разные экземпляры, так и один и тот же экземпляр.

Какой же это нафиг идентификатор, если в РАЗНЫЕ моменты времени он может адресовать РАЗНЫЕ объекты???

В Вашем случае, NativeHandle - контейнер, храняший в себе адрес какого-то объекта. Никакого отношения ни к идентификации, ни к идентификаторам он не имеет, поскольку идентфицировать с помощью него ничего нельзя. NativeHandle - всего лишь банальный адрес.

shuklin
В отличие от ODMG, где каждый объект имеет только один уникальный идентификатор в Cerebrum один и тот же объект может иметь различные идентификаторы.
Неглупые люди, идать в ODMG это все писали. Они то понимали, что такое идентификатор и идентифкация :-)
17 дек 07, 15:15    [5058430]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
как же так, дорогая редакция?
Gluk (Kazan)
Так как вы будете ... реализовывать JOIN не равенству, а скажем по '<' ???
А зачем вообще нужно реализовывать join, ведь насколько я понимаю, задача как раз и состоит в том, чтобы не иметь эту операцию?


знакомая аргументация

Ok, попробую показать для чего бывает нужен JOIN.
Как это ни странно, нужен он бывает не только для того чтобы связать таблички по внешнему ключу.
С его помощью, можно к примеру, построить диаграмму:

SQL> select * from test;

         A          B
---------- ----------
        10          5
        15          7
        27          9
        80          3
        85          1

SQL> select b.MX, nvl(sum(a.B),0)
  2  from test a,
  3      (select 0 MN, 25 MX from dual
  4       union all
  5       select 25, 50 from dual
  6       union all
  7       select 50, 75 from dual
  8       union all
  9       select 75, 100 from dual
 10      ) b
 11  where a.A(+) > b.MN
 12  and a.A(+) <= b.MX
 13  group by b.MX;

        MX NVL(SUM(A.B),0)
---------- ---------------
        25              12
        50               9
        75               0
       100               4

или размножить строки:

SQL> select a.A, b.N
  2  from test a,
  3      (select rownum N
  4       from (select 1 from dual
  5             group by cube (1,1,1,1))
  6      ) b
  7  where b.N <= a.B
  8  order by 1,2;

        A          N
--------- ----------
       10          1
       10          2
       10          3
       10          4
. . .

        27          8
        27          9
        80          1
        80          2
        80          3
        85          1

Прошу прощения у сторонников чистого ANSI-SQL, не пользующегося в Oracle народной любовью.
Подобные задачки часто возникают при формировании разнообразных отчетов, и хочется иметь возможность задавать подобные операции декларативно, а не итерациями на птичьем языке Fetch-ей. Мне до крайности интересно, как будет выглядеть декларативный аналог, предлагаемый вашей КОМД.
17 дек 07, 16:26    [5058936]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
как же так, дорогая редакция?
Gluk (Kazan)
И как вы будете реализовывать n-арные связи ???
Тут я вижу два варианта ответов:

1. (Посложнее) n-арных связей нет, т.е. связь определяется как хранение (одного) адреса. Связь это вещь нематериальная, а потому у связи (в таком определении) не может быть адреса. Адрес есть только у материальных вещей, т.е. у сущностей.

2. (Попроще) Точно так же как и в РМ и в других моделях, т.е. с помощью отдельного типа сущностей, который ссылаются на связываемые сущности.


Ага, конечно. Жопа есть, а слова нету (c)
см. ссылку на Крылова выше
17 дек 07, 16:27    [5058948]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Бред
1. (Посложнее) n-арных связей нет, т.е. связь определяется как хранение (одного) адреса. Связь это вещь нематериальная, а потому у связи (в таком определении) не может быть адреса. Адрес есть только у материальных вещей, т.е. у сущностей.

2. (Попроще) Точно так же как и в РМ и в других моделях, т.е. с помощью отдельного типа сущностей, который ссылаются на связываемые сущности.


Никаких связей, кроме бинарных, нет и быть не может.[/quot]

Опять тихо сам с собою веду беседу ???
Вам бы к доктору сходить. Серьезно
17 дек 07, 16:30    [5058973]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
практикант
Guest
Gluk (Kazan)
Ok, попробую показать для чего бывает нужен JOIN.
Как это ни странно, нужен он бывает не только для того чтобы связать таблички по внешнему ключу.
С его помощью, можно к примеру, построить диаграмму:

SQL> select * from test;

         A          B
---------- ----------
        10          5
        15          7
        27          9
        80          3
        85          1

SQL> select b.MX, nvl(sum(a.B),0)
  2  from test a,
  3      (select 0 MN, 25 MX from dual
  4       union all
  5       select 25, 50 from dual
  6       union all
  7       select 50, 75 from dual
  8       union all
  9       select 75, 100 from dual
 10      ) b
 11  where a.A(+) > b.MN
 12  and a.A(+) <= b.MX
 13  group by b.MX;

        MX NVL(SUM(A.B),0)
---------- ---------------
        25              12
        50               9
        75               0
       100               4

В этом примере join используется как средство выразить неявное отношение принадлежности каждого элемента из первой таблицы какому-то интервалу (элементу второй таблицы). Я не вижу никакой проблемы сделать то же самое с помощью механизма неявных ссылок. Если явная ссылка это значение, которое однозначно идентифицирует целевую запись, то неявная ссылка будет просто выражением, которое будет динамически оценивать наличие ссылки. Используя на лету придуманный язык, можно это записать так:

Table X // Объекты (принадлежат интервалам)
  int A; 
  int B; 
  implicit C references Y { // Вычисляется динамически
    // Если истина, то объект принадлежит интервалу
    (A > Y.MIN AND A <= Y.MAX) == true; 
  } 

Table Y // Интервалы
  int MIN; 
  int MAX; 

Далее группирование вокруг интервалов из Y с последующим агрегированием каких-то свойств из X выполняется тривиально.

Такой подход имеет значительные преимущества:

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

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

3. Неявные связи определяются один раз и далее используются как самые обычные ссылки с отличием, что они вычисляются динамически. В моем примере это поле C в таблице X, которое ни чем не отличается от первых двух (статических или структурных) полей. В запросах не надо каждый раз писать определение. А в join надо. И это вовсе не синтаксические ухищрения.

4. Легко можно использовать многоуровневое (вложенное) группирование, а в РМ разрешается иметь только один GROUP BY.

5. Никаких итераций с циклами тут нет, а просто навигация. Единственное, что мы сделали, это определили неявные или динамические ссылки.
17 дек 07, 17:29    [5059348]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

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

Господин Шуклин, ответьте на один простой вопрос: если объект имеет несколько "идентификаторов", то каким же, позвольте Вас спросить, образом вы этот объект идентифицируете? В одном месте сохранили один "идентификатор", в другом другой, в третьем третий. Итого, в трех разных местах, имеем три разных "идентификатора". Как же нам узнать, что это один и тот же объект?


Данный вопрос нужно разделить на на несколько разных.

- К какому экземпляру мы получим доступ воспользовавшись в первом месте одним идентификатором, в другом месте - другим идентификатором и в третьем - третьем? Ответ: В СУБД/БЗ Cerebrum к одном и тому же экземпляру.

- Откуда СУБД узнает к какому конкретно мы в конкретном случае хоитм получить доступ, чтобы предоставить предыдущий результат? "первое второе и третье места" в СУБД/БЗ Cerebrum представляют собой адресные пространтсва некоторых узлов. Невозможно разадресовать идентификатор в указатель на экземпляр вне заданного узла БД. Каждый узел типа Warden определяет собственное адресное пространство. Вот небольшое эссе на эту тему: http://www.shdsoftware.com/go/00000000002ks34t2pbf7l6v44.html

Как пользователю узнать, что получив два указателя Cerebrum.IConnector на оболочку некоторых экземпляров на самом деле получены оболочки для одного и того же экземпляра узла? Самый простой способ - воспользоваться нерекомендуемым способом: сравнить IConnector,GroundHandle

pavelvp
Идентификатор не может иметь синонимов - это уже не будет идентификатор.

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

Правильно. Этим знанием обладает ядро СУБД. В Cerebrum тем самым true identifier выступает GroundHandle, см. линк выше. Но его исспользование не рекомендуется. Мало того, для незакомиченных объектов он может быть равен NULL В любом случае GroundHandle - особенности реализации и к модели данных отношения не имеет.

pavelvp
Какой же это нафиг идентификатор, если в РАЗНЫЕ моменты времени он может адресовать РАЗНЫЕ объекты???

Ну не указатель же ))) Если вам так проще в понятийном плане - считайте его ключем объекта. Но у меня в СУБД оно называется идентификатором. Точка. )))

pavelvp
В Вашем случае, NativeHandle - контейнер, храняший в себе адрес какого-то объекта.

Неверно. Тип Cerebrum.ObjectHandle хранит именно ИД - номер объекта в БД. Мало того, эти номера задаются Пользователем, а не системой. Т.е. вы как пользователь имеете право положить один и тот же экземпляр одновременно на разные адреса.

pavelvp
Никакого отношения ни к идентификации, ни к идентификаторам он не имеет, поскольку идентфицировать с помощью него ничего нельзя. NativeHandle - всего лишь банальный адрес.

Что это если не идентификатор - философский вопрос. Но уж точно не адрес, см. реплику выше )))

pavelvp
shuklin
В отличие от ODMG, где каждый объект имеет только один уникальный идентификатор в Cerebrum один и тот же объект может иметь различные идентификаторы.
Неглупые люди, идать в ODMG это все писали. Они то понимали, что такое идентификатор и идентифкация :-)

Тем хуже для них :-)
17 дек 07, 18:37    [5059741]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
shuklin
Бред

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

Это не техническое а политико-методологическое решение. Поэтому в технической дискуссии не катит. Что вы посоветуете делать, если на вашей модели некто (пусть даже и не столь квалифицированный разработчик как хотелось бы) соберет запрограммированное и скомпилированное приложение? Что делать с сложившимся фактом? А ведь если модель получит распространение, и не такие чудеса с ней будут вытворять. Итак, что делать технически для обеспечения работоспособности для конкретно приведенного примера? Если слить с темы - тоже ок, запишем этот момент в недостатки вашей модели и подхода.


Нет - это исключительно техническое решение, на реализацию которого и направлены разработки объектных навигаторов на основе КОМД. Конечно, программирование пока остается (хотя многие задачи давно решаются исключительно средствами навигаторов). Но что за "скомпилированное приложение"? С какой темы "слить"? Почему работоспособность будет утрачена при установке новой версии? Пользователю нужно новое приложение (с новыми объектами и/или функциями), но ему нужно старое приложение (со старыми объектами и/или функциями). Хорошая изобретательская задача - не спрорю. Но при чем здесь запросы?
17 дек 07, 19:39    [5059961]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
shuklin
Бред

Еще раз подчеркну, что результатом запроса является удовлетворяющая запросу часть БД со всей присущей БД семантикой. Что касается представления результата и немодельной обработки (агрегирование и т.п.), то здесь фантазия безгранична.

С этим полностью ОК.

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


Допустим у нас есть некоторая БД, вернули результат в той же схеме, приложение довольно, все счастливы. Ну ок. Общие авации продолжались по этому поводу год. Потом изменились требования к приложению. Нужно менять схему БД. А по условиям эксплуатации невозможно сразу заменить все клиентские приложения на новые их версии. Нужно обеспечить обратную совместимость. Т.е. сформирвать некоторые view представляющие схему БД в старом виде для старого приложения, позволив работать с теми же данными ТОЙ ЖЕ ИДЕНТИЧНОСТИ новому приложению уже в новой схеме. Как будем решать эту задачу без трансформации схемы в процессе выполнения запроса?


Еще раз перечитал. Что значит "все клиентские приложения"? Клиент работает с единственным системным "приложением" - объектным навигатором. Именно из него могут запускаться какие-либо прикладные функции, которые на данный момент пока сложно реализовать без программирования. Нужен характерный пример, так как у Вашей задачи может быть совсем другое решение, а не то, о котором Вы говорите. Тем не менее, Ваше решение хотелось бы понять - что значит "трансформация схемы" (на этом же характерном примере)?
17 дек 07, 19:51    [5060001]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
Бред
Нечего сказать на: "Конечно, запрос должен возвращать информацию, а не данные. Именно это и происходит при использовании КОМД. И это принципиально невозможно при использовании РМД без соответствующих надстроек, о которых говорил Злой".

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

Для новеньких.
ЧАЛ расчитывает, на то что он будет повторять. Оппонентам повторно ему отвечать надоест. Тада он скажет: "Нечего сказать". Раньше он сразу в таких говорил: "Раз молчат, значит мы пришли к выводу..." - о "крахе РМД" или "превосходстве ДОМД".


Облажался, дружище, когда попытался ответить по существу. Что за "интерпретацию" несут имена атрибутов в отношениях - результатах алгебраических операций - неизвестно даже самому vadiminfo. И что вообще представляет собой само такое отношение. Даже в базовых отношениях у них имена переменных для программистов, а не "имена атрибутов" для пользователей. И про связи за три года так ничего и не понял. А потрепаться-то хочется. И обижен на себя, к тому же, из-за того, что ничего не может понять. Но я, все-таки, считаю, что во всем виноваты неквалифицированные преподаватели vadiminfo, и он просто жертва "образования".
17 дек 07, 19:59    [5060029]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
наблюдатель и
http://www.izvestia.ru/special/article3111189/
уж и не знаю к чему это я?

Об этом я не подумал. Пусть тада его пустят какой-нибудь семинар, а то доиграемся.


Не волнуйтесь, ничего с "наблюдателем и" не случиться. Он слишком глуп.
17 дек 07, 20:02    [5060039]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ggv
Меня прежде всего интересовало доказательство концепций.
В виде прототипа.
А не мудрствования.
Мудрствования здесь на форуме, и не здесь на формуме, уже много лет безрезультатно идут.
ЧАЛ, я не предлагал семинар изначально - посмотрите внимательно.
Я предлагал вам демонстрацию.
И только.
Вам есть что показать?
Нет - не надо.
Есть - милости просим.


А меня интересует истина, прежде всего. Здесь было много демагогии, хамства и непрофессиональных высказываний по важным вопросам теории баз данных в целом и по моделям данных, в частности. И мы эти вопросы обсудим на семинарах, где не удастся заболтать конкретную тему. Что Вам не нравится? Результат как раз и будет достигнут очень быстро, "безрезультатные мудрствования на форуме" прекратятся. Видимо Вы в этом не заинтересованы?
17 дек 07, 20:12    [5060079]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ModelR
ModelR

как же так, дорогая редакция?

Более того, все запросы содержат на 90% одну и ту же инфу, поскольку таблицы связываются одинаково, поскольку это одна предметная область.
Верно, просто тьма кода содержит
where ... Y.x_id = X.id 
при объявленной связи
FK "xyFK1" Y.x_id ref X.id
Но даже в этом, казалось бы однозначно выигрышном для критики JOIN примере, есть нюансы.
ИМХО довольно практично то, что JOIN симметричен. Как следствие, например FULL OUTER JOIN кроме "FULL OUTER " ничем ситаксически не отличается от JOIN.
Используя же несимметричную запись навигационного типа
X.xyFK1.<Ydata>
Y.xyFK1.<Xdata>
придется FULLить ручками.

shuklin
Отказ от JOIN в явном виде и замена его оператором навигации - точкой "." можно считать очень полезным синтаксическим сахаром.

SCHEME DEPT[].1.EMP[NUM,NAME]
WHERE EMP[SAL]>20K AND DEPT[NUM]='D3'

Все отделы без сотрудников и сотрудники за штатом:
select dept.name, emp.mame
from dept full outer join emp on (dept.dept#=emp.dept#)
where dept.name is null or emp.name is null
как оно будет с сахаром?


SCHEME DEPT[NAME].1.EMP[NAME]
WHERE $EMP.1.DEPT=0 OR $DEPT.1.EMP=0
Этот код придется написать ($="число привязанных экземпляров").

А непосредственно в известных мне навигаторах, естественно без программирования, можно сделать только
SCHEME DEPT[NAME].1.EMP[NAME]
WHERE $EMP.1.DEPT=0
и
SCHEME EMP[NAME].1.DEPT[NAME]
WHERE $DEPT.1.EMP=0

Автоматическая ротация схемы в навигаторе и возможность (интуитивно понятного пользователю) отображения несвязанных экземпляров связанных объектов - очень интересные вопросы. Что касается представлений результатов вне модели, то здесь, как я уже говорил, никаких проблем нет - обычный набор вариантов + полет фантазии разработчиков.
17 дек 07, 20:34    [5060137]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Облажался, дружище, когда попытался ответить по существу. Что за "интерпретацию" несут имена атрибутов в отношениях - результатах алгебраических операций - неизвестно даже самому vadiminfo. И что вообще представляет собой само такое отношение. Даже в базовых отношениях у них имена переменных для программистов, а не "имена атрибутов" для пользователей. И про связи за три года так ничего и не понял. А потрепаться-то хочется. И обижен на себя, к тому же, из-за того, что ничего не может понять. Но я, все-таки, считаю, что во всем виноваты неквалифицированные преподаватели vadiminfo, и он просто жертва "образования".

Вообще-то имена атрибутов не в отношении, а всхеме отношения, ну да ладно.
Про рел алгебру можете почитать у Мейера, хотя зачем Вам это?
Короче, в соседней ветке есть про семинар как раз по кризусу технологий РСУБД.
Надеюсь, Вам там будут рады.
Удачи.
17 дек 07, 20:37    [5060146]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Gluk (Kazan)
Бред
1. (Посложнее) n-арных связей нет, т.е. связь определяется как хранение (одного) адреса. Связь это вещь нематериальная, а потому у связи (в таком определении) не может быть адреса. Адрес есть только у материальных вещей, т.е. у сущностей.

2. (Попроще) Точно так же как и в РМ и в других моделях, т.е. с помощью отдельного типа сущностей, который ссылаются на связываемые сущности.


Никаких связей, кроме бинарных, нет и быть не может.


Опять тихо сам с собою веду беседу ???
Вам бы к доктору сходить. Серьезно[/quot]

Молодец! Ложь и демагогия - залог здоровья на sql.ru.
17 дек 07, 20:37    [5060147]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
Бред

Облажался, дружище, когда попытался ответить по существу. Что за "интерпретацию" несут имена атрибутов в отношениях - результатах алгебраических операций - неизвестно даже самому vadiminfo. И что вообще представляет собой само такое отношение. Даже в базовых отношениях у них имена переменных для программистов, а не "имена атрибутов" для пользователей. И про связи за три года так ничего и не понял. А потрепаться-то хочется. И обижен на себя, к тому же, из-за того, что ничего не может понять. Но я, все-таки, считаю, что во всем виноваты неквалифицированные преподаватели vadiminfo, и он просто жертва "образования".

Вообще-то имена атрибутов не в отношении, а всхеме отношения, ну да ладно.
Про рел алгебру можете почитать у Мейера, хотя зачем Вам это?
Короче, в соседней ветке есть про семинар как раз по кризусу технологий РСУБД.
Надеюсь, Вам там будут рады.
Удачи.


Облажался, и обиделся опять. Ответить по существу нечего, поэтому сослася на реляционную алгебру, в связи с которой как раз и возникла обсуждаемая проблема. Вконец запутался бедолага vadiminfo.
17 дек 07, 20:41    [5060154]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 34 35 36 37 38 [39] 40 41 42 43 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить