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

ТОлько начал читать про неё и ещё не наткнулся на ответ : она клиент серверная или нет, ответьте если вам известен ответ.
14 янв 06, 12:21    [2254777]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
4d_monster
Member

Откуда: Москва
Сообщений: 1613
А как там с метаданными?
С изменением классов?
14 янв 06, 12:30    [2254779]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

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

Ну что Вы, какой тупик.

Не из тупика, а из скорлупы. Автором топика названо скорлупой использование SQL. Но РСУБД он скорлупой не считает. По ходу, и ранее возникли мысли у кое-кого, что скорлупа РСУБД в целом.

mv

1. первый - сущности представляются набором таблиц, и 2. - второй - сущности
представляются набором объектов.

Первый вариант - скорлупа из которй хочет вывести всех, например Шаклин.

Я в курсах из толстой литры и прежних топиков на этом форуме про ООСУБД - 2 торой вариант.
Вот и спрашивал не нашли ли чего нового в этом втором варианте в этом топике, чтобы выйти из якобы скорлупы.


mv

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

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

mv

Предлагается либо использовать первый ("реляционный") подход к
проектированию бизнес - модели,

Предлагается? Да счас пока еще эпоха "реляционного" подхода. Он давно предложен и нашел успех. От того его и считаю аппоненты скорлупой.


mv

В данном случае предлагаю использовать ОО СУБД, благо в
добавок к Cache (ОО ?) и Versant появились бесплатные, open - source db40,
Goods и т.д.


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


mv

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


Так они противостоят изначально. ООМД отрицает РМД. Их непротивоставление дает - ОРСУБД. Но оно противостоит ООСУБД. Они конечно могут поделить рынок, но противостояние останется.
14 янв 06, 15:59    [2255034]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Ключевой вопрос, на который нужно ответить для неформального понимания реляционной теории, в частности, и теории баз данных, в целом, и их практической пользы: как используются на практике формальные конструкции реляционной (и любой другой) модели данных.
Вот мод справедливо обратил внимание на несуразность формулы: объект1[операция]объект2=объект3. Но ведь отношение1[алгебраическая операция]отношение2=отношение3 - это чистая математика. На практике же получаем ту же самую несуразность. Абсолютно ту же самую. С помощью каких конструкций в РМД представляются сущности и связи между сущностями реального мира ? С помощью отношений и ключей (здесь долго пытались оспаривать Кодда и Дейта, которые ясно дали понять, что отношения представляют сущности и связи между сущностями, а внешние и первичные ключи нужны опять же (!) для связей между сущностями). И точно так же непонятно, что это за отношение(сущность)1[операция]отношение(сущность)2=отношение(сущность)3.
На самом деле схема результата должна в точности соответствовать схеме той части БД, к которой сделан запрос (если мы не говорим о системах ИИ, выводящих новые знания). Содержание этого результата (экземпляры объектов) зависит от условий "запроса", и для этого результата могут быть различные внешние представления, например, в виде таблицы. А многие здесь путают РЕЗУЛЬТАТ (по сути, по семантике) и ПРЕДСТАВЛЕНИЕ результата (форму).
Реляционная теория противоречива. Вычислительная компонента протеворечит семантической компоненте. И "сторонники" этой теории постоянно игнорируют в любых спорах семантику, идентификацию и навигацию (это базовые принципы общей теории баз данных) поскольку их просто нет в реляционной теории, и упорно гордятся возможностью складывать апельсины с автомобилями. Этим же самым гордится и представитель Zigzag.
mv решил почему-то проигнорировать мнение Кодда, Дейта и других исследователей, что между сущностями есть связи. И в 2254629 упомянул два подхода, практически равнозначных и одинаково бесперспективных: 1. отношения, 2. объекты - для представления сущностей и связей (об этом он просто забыл) между сущностями. Такой же по сути подход и у Shuklin. Есть еще "гремучая смесь" с ОР-маппингом - это уже просто от концептуального бессилия. И почему mv Вы употребили слово "противопоставлять" ? То есть противопоставлять, конечно, не нужно. Но нужно обязательно сопоставлять, сравнивать. Можно сравнивать db40 с другими ООСУБД. Но это не в тему. А что дает эта СУБД в плане идентификации, навигации и семантики, как в ней представляются связи между сущностями ? Что она дает по сравнению с SQL ? Неужели в любой другой СУБД "создать Миху Шумахера" сложнее ? Где Вы видели СУБД без "транзакций", "индексов" и "горячего бэкапа" ? То есть почему ЭТО должно быть ИНТЕРЕСНО ?
14 янв 06, 16:08    [2255042]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Стало быть коллега ЧАЛ опять нарисовался с якобы общей теорией баз данных. В него как выводителя из скорлупы уже совсем мало кто верит. Может быть тока не помню кто, но это его же клон. Да и вывести он может тока в доскорлупную эпоху - прядо к динозаврам. Т.е. завести то может, а вот выводить не по его части. Ну хоть поржать можно будет от души над его мыслями про БД.
Спросите у ЧАЛ про эту якобы теорию. Что там за теоремы или что там есть. Мне лично о таковой слышать не доводилось.
А вот теория РБД есть с теоремами как положено. Это еще одно серьезное препятствие для выхода из скорлупы.
14 янв 06, 17:11    [2255119]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
А демагог vadiminfo наверное постоянно здесь болтает про "теоремы", и принципиально не высказывается по существу. Над его высказываниями даже поржать не удастся.
14 янв 06, 17:44    [2255144]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

А демагог vadiminfo наверное постоянно здесь

Ну так он в отличии от ЧАЛа и не объявлял о своих уходах многократно. Тем более не создавал клонов, чтобы навязывать свои мыстли через якобы последователей.

Чернышев Андрей Леонидович

болтает про "теоремы", и принципиально не высказывается по существу.

Это вместо того, чтобы привести таки теоремы из якобы общей теории.
Или это теория без теорем? Одни тока тезисы не имеющие обоснования?

Чернышев Андрей Леонидович

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

А разве ЧАЛа мало, чтобы ржать над его опусами. Зачем еще кто-то нужен на это место?
14 янв 06, 19:44    [2255218]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Это хорошо, что штатный демагог vadiminfo подтвердил, что постоянно здесь болтает про "теоремы", и принципиально не высказывается по существу.
14 янв 06, 22:17    [2255325]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

Это хорошо, что штатный демагог vadiminfo подтвердил, что постоянно здесь болтает про "теоремы", и принципиально не высказывается по существу.

Ну вот и ЧАЛ дождался чего-то хорошего. Громко простившись, он не ушел, стало быть, не зря. Конечно, дореляционной ОМД это не поможет. Чистая математика для него так же останется недоступной в силу природы его образования, но от нее ради него, а тем более ради его файловых систем на МУМПСе никто по прежнему не откажется. В БД, судя по сумбурному набору слов в его текстах, он и дальше намерен разбираться как свинья в апельсинах. Но все-таки маленькие радости этому отставшему от жизни ИС незадачливому коллеге достались.
Бум ждать что он еще выдаст, чтобы поржать. Жаль тока он повторяет одно и то же - типа заело. Мог бы придумать что-нить уже новенькое про РМД (а еще лучше про свою дореляционку), чтобы смешнее было. Все-таки он же должен был за это время своего отсутсвия что-то надыбать. Или он иссяк?
15 янв 06, 00:48    [2255525]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
правильно ли я понял, что в НРМ нельзя написать
новый объект z = объект x операция объект y
но можно expand существующий объект z ссылками на объект x и объект y
сравните с РМД
новая таблица z = таблица x операция таблица y

Я не понял ни
новый объект z = объект x операция объект y
ни
новая таблица z = таблица x операция таблица y


Что имееся в виду и что, собственно, вызывает раздражение? Поясню свое непонимание.

Есть операция деления
2 / -3 = 0.6(6)

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

Теперь начнем с конца - с
сравните с РМД
новая таблица z = таблица x операция таблица y
Я не понимаю. В РМД нет таблиц. Таблица - это что-то из SQL и это понятие смешивает понятие "значение" (отношение) и "переменная". С точки зрения РМД в отношение1 операция отношение2 = отношение3 вещь не более странная, чем 1+2=3. И не о каких новых отношениях (значениях) речь при этом не идет, поскольку мы получаем значение из множества возможных значений.

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

Теперь переходим к объектам. Заранее поясню, что для меня объект - это нечто, что соденияет переменную и значение. Поэтому
автор
новый объект z = объект x операция объект y
представляется мне мягко говоря надуманным. То есть я такого даже припомнить не могу. Есть операция new создающая новую переменную типа. И есть операции присваивающие значение это переменной.

(1)объект z = new типобъекта // создание новой переменной
(2)объект z = объект x операция объект y //типа присваиваем значение

Здесь самое главное понимать, что манипулируя объектом мы используем ссылки. Так вот - в НРМ выражение (2) невозможно. То есть синтаксически это корректное выражение, но оно однозначно обозначает, что часть объект x операция объект y возвращает ссылку, которое присваивается ссылочной переменной объект z. Другими словами, после операции объект z = .... значение объектой переменной, на которую указывала ссылочная переменная объект z не поменяется, однако. возможно, что эта ссылочная перменная будет ссылаться на другой объект. Для того, что бы изменить состояние объекта (т.е. изменить значение, лежащее в объектной переменной) мы должны указать компонент объекта - его атрибут или метод.

С другой стороны, в НРМ операция new к ссылочному типу неприменима.

Если Вы попытаетесь перефразировать вопрос в свете сказанного, то я постараюсьна него ответить.

2 Vadininfo и ЧАЛ Кончайте сраться, господа....
2 ЧАЛ Тююююю.... а вроде кто-то ушел навсегда.....:)
15 янв 06, 01:34    [2255585]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mv
Member

Откуда:
Сообщений: 8876

Читатель флейма

db4o - платна, не при комерческом использовании, а при использовании в не
GPL продуктах. Это для некоторых важно.

Виноват, был неточен. (я как раз из тех, кому это неважно).
Ну, вобщем - если платить не хочешь - то должен все исходники своего
продукта предоставить. (если я опять ничего не перепутал).

Читатель флейма

Только начал читать про неё и ещё не наткнулся на ответ : она клиент
серверная или нет, ответьте если вам известен ответ.

Она используется "в двух видах".
Первый как встроенная СУБД - так, как я показал в примере.

Второй - как клиент-серверная. Чтобы использовать ее как клиент -
серверную - нужно добавить несколько строк кода. Чтобы "приготовить" сервер.
Там (в "доке" - tutorial.pdf и на форуме у них) примерчики есть.
Да, несколько непривычно, но довольно просто.
Ну вот, этот сервер может быть расположен на любой машине. Или опять же - в
том же приложении (чтобы работать в многопоточном режиме, например)

vadiminfo

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

Дык, кто ж его знает...
Вон, у меня программки были (и до сих пор кое-где есть) на Clipper
(Summer87), кто же знал, что если число записей превысит некоторый порог (на
сегодняшний день просто смешной), то поск по индексам будет глючить? И что
от фирмы - разработчика рожки да ножки останутся?

Тесты настряпать - нефик делать. Я вон, попытался сделать выборку 1 млн
объектов - и эксцпшн схлопотал. Потому что для таких извращений виртуальную
машину Java нужно настраивать. (А еще лучше - вообще такого не делать ).
Есть недостатки, да. Но эти ребята (из db4o.com) оперативно реагируют и
предлагают решения.

Мне кажется, что потратать день на ознакомление, и два - три дня на тесты -
совсем не такая большая цена. На форуме больше времени проводим.

А если более серьезно - то наша контора сейчас экспериментирует. ПОка
устраивает. На сегодняшний день решили, что если будут проблемы с
быстродействием/масштабируемостью/функциональностью - то будем рассматривать
продукты Versant. Но пока вроде устраивает.

vadiminfo

Так они противостоят изначально. ООМД отрицает РМД. Их непротивоставление
дает - ОРСУБД. Но оно противостоит ООСУБД. Они конечно могут поделить рынок,
но противостояние останется.

Ну и что? Вы считаете, что специалист, имеющий опыт разработки и с помощью
объектной модели, и с помощью реляционной - это потерянная личность?
Вон ламеры из BMW и Boeng вовсю юзают эту db4o, и ничего. Хотя кто их
знает - может они каждое утро начинают с сожжения книг Кодда, Дейта...
Так что будте начеку! (Летайте самолетами Аэрофлота и ездите на Жигулях).


ЧАЛ


Уважаемый, я не в силах оценить всей глубины Ваших мыслей, поэтому Вы зря
тратите время на комментарии моих постов. Я даже некоторые Ваши фразы до
конца проитать не смог.
Я простой программер - прикладник. Военнослужащий в добавок. Не издевайтесь,
пожалуйста...
....
Хочешь - пришлю Вам пару банок пива, а то тоскливый Вы какой-то...
"Алиса, выпей вина!" (с)
-------------------------------
4d_monster

А как там с метаданными?
С изменением классов?

Да кто ж его знает, как там с метаданными?
Ну, Вы же видели - я просто сохраняю ЛЮБОЙ вариант ЛЮБОГО класса (в т.ч. со
свойствами ссылочного типа - Другой_Класс, Массив, Коллекция и т.п. - это я
ЧАЛу (не отвечать!) ):
db.set(any_instance);
.... и все. СУБД сама извлекает из экземпляра класса данные о его структуре,
и соответственно организует работу с метаданными. (Вот Вам и недостаток -
- только языки с рефлексией могут юзать эту db4o - Java, .Net (VB, C#,
C++ managed, Delphi for .Net...), Mono (хрен его знает - что там за
языки...))
Если добавть новое поле в описание класса - то все равно работать будет.
Просто при извлечении ранее записанных данных значения "новых" полей будут
дефолтным (для типа int - это будут нули, для String - и других ссылочных
типов - null и т.д.). Если убивам поле в описании класса - то оно в базе
становится недоступным.
Короче - с, мечта идиота.

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

Ну, в общем три вещи отслеживаются автоматически:
- изменение интерфейса или API к классу
- добавление поля
- удаление поля.

Переименование (думаю, в примере все будет ясно):
// Переименование класса

Db4o.configure().objectClass("package.class").rename("newPackage.newClass");

// Переименование поля

Db4o.configure().objectClass("package.class").objectField("oldField").rename
("newField");


Изменение типа. Если Вы такое сотворите - то db4o ("...у ея внути неонка
есть...") создаст еще одно поле - нового типа. Т.е. данные старого типа
будут лежать в старом поле, а новые - в новом.

Не автоматизированы (как утверждают - пока) некоторые вещи. Например, если
вы переместите класс внутри иерархии. (а как тут можно автоматизировать?)
Тут ручками придется поработать. Вот так, например:

- Создаем новый класс (с временным именем) в новом месте иерархии
- ручками создаем объекты новго класса на основе старого
- удаляем старые объекты
- переименовываем новый класс с временным именем в "старое имя"

Ну, еще кое-что подобное .

Естественно - не все так просто. Например - если объектов миллион, то поиск
тормозить будет. Поэтому есть возможность при создании базы объеявить, что
такие-то и такие-то поля следует проиндексировать.
Т.е. с метаданными все же приходится иногда работать...

***************
Вообще-то они упорно проталкивают эту свою ООСУБД как СУБД с нулевум уровнем
администрирования, но нас-то не нае#ешь, рано или поздно что-то случится...
(иначе нафига бы они, к примеру, "горячий" бэкап вводили?)
***************

А зачем все это? Ну, мне это удобно. По скорости устраивает. Лично для меня
проектировать систему в разрезе объектной модели удобнее.
Разве мало?
Если пойму, что использование РСУБД в ДАННОЙ КОНКРЕТНОЙ ЗАДАЧЕ лучше, и
выигрышь при ее использование превышает выигрышь при использовании ООБД -
буду использовать РСУБД. И наоборот.

Какие- проблемы - то?

Posted via ActualForum NNTP Server 1.3

15 янв 06, 05:09    [2255636]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Замечание от U-gene подействовало на меня, и я не обижаюсь на vadiminfo (надеюсь, что в 2255042 я ничего обидного не сказал). И даже считаю, что он знаком с общей теорией баз данных, но просто хочет освежить некоторые аспекты за мой счет, так сказать, в рамках данной темы.

Общая теория баз данных излагается в любой (или почти любой) книге по базам данных. Это, в первую очередь, основные понятия, термины и определения.

>Дейт:

"База данных - это некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия."

>Далее объясняется что именно представляют собой "данные предприятия":

"...Проекты, детали, поставщики и т.д. представляют собой основные СУЩНОСТИ (entity), о которых ... необходимо хранить информацию. В теории баз данных [!!! - А.Л.] термин СУЩНОСТЬ обычно используется для обозначения любого различимого объекта, который может быть представлен в базе данных...
Кроме этих основных сущностей ... имеются еще и СВЯЗИ (relationship) между ними...
...связь ... является такой же неотъемлемой составляющей данных предприятия, как и основные сущности. Поэтому связи должны быть представлены в базе данных наравне с основными сущностями предметной области."
>Конец цитаты.

У Дейта, "естественно", крайне тенденциозное изложение общей теории баз данных из-за того, что он уже в этой части нацелен на приоритет РМД. Например, он излагает основы идентификации и навигации умышленно не употребляя этих терминов (но употребляет их потом при изложении РМД для "критики" !):

"В частности, используя связь ... между поставщиками и деталями, можно ответить на следующие вопросы:
- задан [!!! - А.Л.] поставщик, и требуется определить поставляемые им детали;
- задана [!!! - А.Л.] деталь, и необходимо найти поставщиков, предоставляющих такую деталь."
>Конец цитаты.

Логично было бы вслед за изложением основных понятий теории баз данных (туда входят еще "свойства", "модель данных" и др.) привести те результаты исследований, которые имеют именно общий характер, и используют именно ЭТИ основные понятия. То есть привести, например, такие "модели данных" как ER-модель (о ней речь идет только в гл.14). Тем более, что при использовании на "логическом уровне" любой частной "модели данных" (например, РМД) модель, соответствующая общей теории баз данных, ВСЕ РАВНО ИСПОЛЬЗУЕТСЯ при проектировании баз данных. Собственно с нее все и начинается. И СОВЕРШЕННО ОЧЕВИДНО, что в ИДЕАЛЕ ей все (проектирование) должно и заканчиваться !
Потом можно было написать что-то типа "идеал не достижим при современном уровне развития...", поэтому на "логическом уровне" несчастному человечеству ПРИХОДИТСЯ использовать, например, реляционную модель данных.

Может быть теперь и mv станет понятнее что написано в 2255042. Хотя судя по его последнему сообщению, несмотря на общепринятое пренебрежительное отношение к моим сообщениям, он, все-таки, задумался, и даже кое на что ответил. Допускаю, впрочем, что он не понял, например, разницу между результатом "запроса", и представлением результата. Рекомендую для понимания сделать простой запрос к отношению (термин частной реляционной теории) Человек{Идент., Фамилия, Вес} с отбором только тех кортежей (термин частной реляционной теории), у которых Вес>100 и с получением суммы по атрибуту (термин частной реляционной теории) Вес. И рассмотреть результат этого "запроса" в рамках общей теории баз данных, частной реляционной теории, и реальной СУБД (следует особо обратить внимание на то, какой кортеж какого отношения будет представлять итоговый вес в результате запроса в реляционной теории).
15 янв 06, 12:48    [2255811]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

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

Мне кажется, что потратать день на ознакомление, и два - три дня на тесты -
совсем не такая большая цена. На форуме больше времени проводим.

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

mv

Вы считаете, что специалист, имеющий опыт разработки и с помощью
объектной модели, и с помощью реляционной - это потерянная личность?

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

Чернышев Андрей Леонидович

Общая теория баз данных излагается в любой (или почти любой) книге по базам данных. Это, в первую очередь, основные понятия, термины и определения.

Но там про то, что это общая теория ни слова, наскока я помню. Основные понятия, термины и определения есть даже в доке про ЖЭК. Для теории этого маловато буит. Зато есть теория РБД. С теоремами - все как положено. А Дореляционная ОМД - это просто ремесло, а никакая не наука. И к наукам и теориям не может иметь решительно никакого отншения. Тем более что и как ремесло его можно признать не удачным -оно кануло в лету и имеет тока историчекое значение, как отрицательный опыт ранних попыток поисков решений.
15 янв 06, 17:19    [2256236]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
c127
Guest
Чернышев Андрей Леонидович

Логично было бы вслед за изложением основных понятий теории баз данных (туда входят еще "свойства", "модель данных" и др.) привести те результаты исследований, которые имеют именно общий характер, и используют именно ЭТИ основные понятия. То есть привести, например, такие "модели данных" как ER-модель (о ней речь идет только в гл.14). Тем более, что при использовании на "логическом уровне" любой частной "модели данных" (например, РМД) модель, соответствующая общей теории баз данных, ВСЕ РАВНО ИСПОЛЬЗУЕТСЯ при проектировании баз данных. Собственно с нее все и начинается. И СОВЕРШЕННО ОЧЕВИДНО, что в ИДЕАЛЕ ей все (проектирование) должно и заканчиваться !
Потом можно было написать что-то типа "идеал не достижим при современном уровне развития...", поэтому на "логическом уровне" несчастному человечеству ПРИХОДИТСЯ использовать, например, реляционную модель данных.

Может быть теперь и mv станет понятнее что написано в 2255042. Хотя судя по его последнему сообщению, несмотря на общепринятое пренебрежительное отношение к моим сообщениям, он, все-таки, задумался, и даже кое на что ответил. Допускаю, впрочем, что он не понял, например, разницу между результатом "запроса", и представлением результата. Рекомендую для понимания сделать простой запрос к отношению (термин частной реляционной теории) Человек{Идент., Фамилия, Вес} с отбором только тех кортежей (термин частной реляционной теории), у которых Вес>100 и с получением суммы по атрибуту (термин частной реляционной теории) Вес. И рассмотреть результат этого "запроса" в рамках общей теории баз данных, частной реляционной теории, и реальной СУБД (следует особо обратить внимание на то, какой кортеж какого отношения будет представлять итоговый вес в результате запроса в реляционной теории).


Вы бы сначала разобрались что такое упорядоченное множество, а потом уже бы поучали других и рассуждали бы о том что логично а что нет и о прочих высоких материях. А то странно как-то слышать нравоучения и рассуждения о нелогичности РМД от человека, который не в состоянии ответить упорядочено ли множество {1,2,3,4,5}, и утверждающего, что в реляционной модели (читай в теории множеств) множество упорядочить невозможно на том основании что это нельзя сделать с шариками в мешочке (https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=16#1930974 ).

"Шары, пропущенные через упорядоченный список" (С) ЧАЛ, 3 окт 05, 23:35, https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=17#1934369
15 янв 06, 23:41    [2256553]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
мод
Guest
Чернышев Андрей Леонидович
А многие здесь путают РЕЗУЛЬТАТ (по сути, по семантике) и ПРЕДСТАВЛЕНИЕ результата (форму).
и упорно гордятся возможностью складывать апельсины с автомобилями. ?

вот в этом и состоит принципиальное отличие "объектного" или "семантического" подхода от формального
при формальном подходе мы произвольно манипулируем формальными структурами данных (списками, таблицами, матрицами, массивами и т.д.) присваивая им нужную нам семантику
select a.*,b.* from a,b где a,b апельсины с автомобилями мы получаем декартово произведение апельсинов с автомобилями но семантика результата автору д.б. известна
поэтому как я уже говорил мы моделелируем сущности формальными структурами данных и затем манипулируем не сущностями а этими стр-ми
А SQL просто один из языков для описания и манипулирования формальной структурой данных - таблицами. Можно придумать другой язык для таблиц. Есть языки для других формальных структур. Вот где выход из SQL. Ищите и обрящите.
16 янв 06, 10:26    [2257094]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

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

вот в этом и состоит принципиальное отличие "объектного" или "семантического" подхода от формального
при формальном подходе мы произвольно манипулируем формальными структурами данных (списками, таблицами, матрицами, массивами и т.д.) присваивая им нужную нам семантику
select a.*,b.* from a,b где a,b апельсины с автомобилями мы получаем декартово произведение апельсинов с автомобилями но семантика результата автору д.б. известна
поэтому как я уже говорил мы моделелируем сущности формальными структурами данных и затем манипулируем не сущностями а этими стр-ми
А SQL просто один из языков для описания и манипулирования формальной структурой данных - таблицами.

А в объектоном подходе хождение по ссылкам и индексам - сама семантичночть что-ли? Не формально? В SQL ассоциативный запрос по содержанию и относительно близко к естественному языку по синтаксису - это гораздо семантичней, навигации по ссылкам и индексам. Так что не надо на дурачить.
16 янв 06, 12:23    [2257640]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Чернышев Андрей Леонидович
Но ведь отношение1[алгебраическая операция]отношение2=отношение3 - это чистая математика. На практике же получаем ту же самую несуразность.
То есть, скажем, 2+2=4 — это для Андрей Леонидовича чистая математика, на практике дающая абсолютную несуразность? И как же люди математикой веками пользуются, просто загадка. Для него.
Чернышев Андрей Леонидович
На самом деле схема результата должна в точности соответствовать схеме той части БД, к которой сделан запрос (если мы не говорим о системах ИИ, выводящих новые знания).
Почему должна? Доказательства, цитаты?
И вот вопрос. Пусть в БД хранятся «сущности» СТУДЕНТЫ, ПРЕДМЕТЫ, ОЦЕНКИ_СТУДЕНТОВ_ПО_ПРЕДМЕТАМ (будь это хоть отношения в РБД, хоть классы в ОБД). Запрос: вычислить для каждого студента общий средний балл, вроде:
Фамилия: Средний балл:
Иванов: 4,4
Петров: 5,0
Сидоров: 3,8
Если точка зрения ЧАЛ верна, то этот результат должен удовлетворять той же подсхеме, что и «область запроса». То есть указанные результаты надо как-то «приткнуть» в схему СТУДЕНТЫ, ПРЕДМЕТЫ, ОЦЕНКИ_СТУДЕНТОВ_ПО_ПРЕДМЕТАМ. Очевидно, что во-первых, приткнуть ее туда невозможно (нет в ней нигде поля «Средний балл»), а во-вторых, нахрена в этой схеме результата ПРЕДМЕТЫ и ОЦЕНКИ_СТУДЕНТОВ_ПО_ПРЕДМЕТАМ, ежели они в самом результате вовсе не нужны?
Чернышев Андрей Леонидович
Реляционная теория противоречива. Вычислительная компонента протеворечит семантической компоненте.
Набор слов. Как и всегда. Доказательств ноль, гонору до неба.
16 янв 06, 13:04    [2257910]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
mir
Очевидно, что во-первых, приткнуть ее туда невозможно (нет в ней нигде поля «Средний балл»)


На самом деле можно - можно ввести фиктивный предмет - "Средняя оценка".

Однако ИМХО правильнее тут создать новый класс и новый экземпляр. Что и происходит неявно в случае выполнения SELECT ...
16 янв 06, 13:46    [2258162]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
okdoky
Member

Откуда:
Сообщений: 349
SergSuper
Допустим у нас есть некая иерархическая структура: сотрудник, его заплата, его начальник. У начальника естественно тоже может быть начальник. Надо узнать сколько какой начальник получает с его подчинёнными.

okdoky
сотрудники
сотрудник; зарплата; начальник
Петров ; 400; Злюкин
Иванов ; 300; Злюкин
Злюкин ; 600; Смотренко
Смотренко; 1000

Если говорить об иерархической зависимости начальников в таблице "сотрудники" на Zigzag я мог бы использовать такой скрипт:
сотрудник:
(имя:Смотренко, зарплата:1000):
(имя:Злюкин, зарплата:600, начальник:Смотренко):
[(имя:Иванов, зарплата:300, начальник:Злюкин), (имя:Петров, зарплата:400, начальник:Злюкин)];
$x = сотрудник:(имя:Смотренко):;
$printTable($x, имя, зарплата);

Фактически мы определили такую иерархическую зависимость:
сотрудник:1:2:[3,4]. Ответ будет:
имя; зарплата
Смотренко; 1000
Злюкин; 600
Иванов; 300
Петров; 400

SergSuper
т.е. это Вы написали типа запрос
select имя, зарплата from сотрудник
Но я то просил узнать сколько какой начальник получает с его подчинёнными. Т.е. например у Злюкина должно быть 1300

Это был запрос относительно зарплаты Смотренко и всех его подчиненных. Через
$x = сотрудник:(имя:Смотренко)
переменной $x мы присваиваем множество объектов имеющих отношение с именем Смотренко.
Через =$x: мы можем обратиться ко всем объектам более нижнего уровня в иерархии. Соответственно, через
$x = сотрудник:(имя:Смотренко):
переменной $x мы присваиваем не только сотрудников с именем Смотренко, но и всех сотрудников более нижнего уровня.
Если вас интересует и суммарный подсчет зарплаты, можно использовать скрипт
$x = сотрудник:(имя:Смотренко):;
$printTable($x, имя, зарплата);
$printLine("ИТОГ:", $sum($x, зарплата));
В последней строке функция $sum подсчитывает сумму значений атрибута зарплата у всех объектов $x. Результат будет:
имя; зарплата
Смотренко; 1000
Злюкин; 600
Иванов; 300
Петров; 400
ИТОГ: 2300
Можно составить отчеты и для других начальников, Злюкин и т.д.. Уверяю, что необходимый для этого цикл в Java/Zigzag будет смотреться несложно. Давайте остановимся пока только на простом примере, подсчете зарплаты для Смотренко и его подчиненных. Интересно, как будет решена та же задача на SQL и в db4o? Я лично пока ничего лучше не вижу кроме, как создать в PL/SQL процедуру типа
CREATE OR REPLACE PROCEDURE inferiors (chief IN "сотрудники"."начальник"%TYPE) AS
с рекурсивным обращением к самой себе и просмотром внутри ее всех непосредственных подчиненных через цикл для
CURSOR direct_inferiors IS  
SELECT сотрудник FROM сотрудники WHERE начальник=chief;
Кто-нибудь из скулистов продемонстрируйте как будет реально выглядеть на SQL или PL/SQL программа подсчета зарплаты для Смотренко и его подчиненных? Можно исходить из того, что приведенная выше таблица "сотрудники" уже присутствует в базе данных. Интересно посмотреть ответ и от mv. Как будет выглядеть программа составления отчета в db4o? Раз вы его хвалите, значит знаете. А если не знаете, есть возможность изучить. Уверен, что в ОО или ОР СУБД проход от начальника ко всем нижестоящим сотрудникам будет выполняться значительно быстрее, чем в РСУБД.
16 янв 06, 13:50    [2258176]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Интересно, как будет решена та же задача на SQL и в db4o? Я лично пока ничего лучше не вижу кроме, как создать в PL/SQL процедуру типа

CREATE OR REPLACE PROCEDURE inferiors (chief IN "сотрудники"."начальник"%TYPE) AS
с рекурсивным обращением к самой себе и просмотром внутри ее всех непосредственных подчиненных через цикл для

CURSOR direct_inferiors IS SELECT сотрудник FROM сотрудники WHERE начальник=chief;

Почитайте про рекурсивные запросы в Оракле/MSSQL2005/DB2/ASA 9, а так же и OLAP-функции в запросах - и Вам станет ясно, что эта и более сложные задачи решаются одним элементарным запросом, без процедур, циклов и рекурсивных вызовов. Не знаю, как в Оракле, но могу точно сказать, что для той же ASA, для рекурсивных запросов и OLAP еще ко всему прочему неплохо помогает встроенный оптимизатор запросов, имеющий в загашнике различные алгоритмы способов обработки данных и под такие запросы и достаточно компентентный в праве выбора нужных алгоритмов в зависимости от ситуации.

P.S. Ну а Ваш предложенный для РСУБД вариант конечно же является заведомо проигрышным в скорости, так как Вы изначально видите решение только в разрезе своего опыта обработки информации и пытаетесь вместо решения подогнать известную Вам реализацию :)
16 янв 06, 14:05    [2258269]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Если правильно понял про что Вы то в Оракле:

SELECT sum(зарплата) FROM персонал
START WITH сотрудник = 'Смотренко'
CONNECT BY PRIOR сотрудник = начальник

Вернет
2300

Если надо чтобы с фамилиями и результирующим

SELECT сотрудник, sum(зарплата) FROM персонал
START WITH сотрудник = 'Смотренко'
CONNECT BY PRIOR сотрудник = начальник
GROUP BY ROLLUP(сотрудник)
16 янв 06, 14:18    [2258344]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
мод
Guest
vadiminfo

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

в киеве дядька
ессно работа с формальными стрктурами м.б. гораздо "семантичнее" любой "объектной" прилады
16 янв 06, 15:06    [2258622]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
shuklin
mir
Очевидно, что во-первых, приткнуть ее туда невозможно (нет в ней нигде поля «Средний балл»)


На самом деле можно - можно ввести фиктивный предмет - "Средняя оценка".

Однако ИМХО правильнее тут создать новый класс и новый экземпляр. Что и происходит неявно в случае выполнения SELECT ...
В Киеве дядька-2. Для тех, кто в танке. Речь идет о генияльной мысли ЧАЛа "схема результата должна в точности соответствовать схеме той части БД, к которой сделан запрос". Читаем тему, читаем, не ленимся.
16 янв 06, 17:11    [2259257]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
mir
shuklin
mir
Очевидно, что во-первых, приткнуть ее туда невозможно (нет в ней нигде поля «Средний балл»)


На самом деле можно - можно ввести фиктивный предмет - "Средняя оценка".

Однако ИМХО правильнее тут создать новый класс и новый экземпляр. Что и происходит неявно в случае выполнения SELECT ...
В Киеве дядька-2. Для тех, кто в танке. Речь идет о генияльной мысли ЧАЛа "схема результата должна в точности соответствовать схеме той части БД, к которой сделан запрос". Читаем тему, читаем, не ленимся.


Об этом и речь. В данном конкретном случае, именно в данном, введение фиктивной строки в справочник "ПРЕДМЕТЫ" позволяет провести выборку из БД с сохранением структуры БД.

А ващето я согласен с ЧАЛ в том объеме, что часто удобно, когда "схема результата в точности соответствовует схеме той части БД, к которой сделан запрос" (без слова "должна") и в ОБД это один из дополнительных плюсов, когда можно выбрать некоторое подмножество экземпляров связанных указателями объектов, а не их копий. Однако так же согласен с Вами, что в конкретном примере правильнее изменить схему результата вместо того, чтобы вводить фиктивные записи в справочник. В ОБД ввод фиктивных записей будет соответсвовать введению фиктивных экземпляров персистент объектов, а изменение результата - будет соответсвовать введению нового "adhoc" класса. Этот новый adhoc класс будет являтся объектным JOIN или в терминах ООП - аггрегатом.
16 янв 06, 18:07    [2259529]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Тот "спор", с127, скорее не со мной, а с Коддом и Дейтом, Вы проиграли вчистую. Впрочем, напомню Вам, что как Вы потом признались - Вы просто шутили. Подключайтесь теперь к новому, совсем вроде бы простому вопросу: запрос сделайте из 2255811 и изучите результат. А то никто упорно не хочет этого делать, видимо чувствуют какой-то подвох ?
16 янв 06, 19:23    [2259746]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 39   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить