Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 39   вперед  Ctrl
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
Кроме шуток - видел реализацию защищенной кандидатской. СУБД была Oracle.

Так вот - вместо использования order by, автор написал собственную функцию для сортировок. Прям так - грузим всю таблицу в память и сортируем методом пузырька. Period.

Так вот теперь я понял - это был ЧАЛ, он прочитал что order by не является реляционным отношением :-)
31 янв 06, 12:19    [2304571]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
глупость человеческая бесконечна...
извратили само понятие научного труда...
Ироды.
31 янв 06, 12:22    [2304593]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

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

Если ответить конкретно, то у поля-коллекции тип NativeVector (в следующей версии NativeVector будет удален и заменен на более другие механизмы), а у поля с одной связью - Scalar. Это если резать объект. А если сериализовать как единый монолит, то коллекция System.Collections.ArrayList а поле - NativeHandle.
Теперь по человечески. поле коллекция представляет собой аттрибут в котором находится объект сложной структуры. Этот объект реализует коллекцию указателей. Либо такую коллекцию можно реализовать внутри самого объекта как ArrayList и реализовать кастом сериализацию. Поле с указателем предсавляет собой скалярный объект и хранит в себе экземпляр NativeHandle, либо это может быть поле класса, которое участвует в кастом сериализации. У обеих подходов есть и достоинства и недостатки. Реализовать способ с одними достоинсвами и без недостатков у меня не вышло - поэтому поддерживаю оба варианта.


Чернышев Андрей Леонидович
Как ЦЕЛОСТНО описать связь ?

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

Чернышев Андрей Леонидович
То есть откуда известно, что данная "коллекция однонаправленных" в партнере и данная "одна однонаправленная" в договоре - это одна бинарная связь ?

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

Чернышев Андрей Леонидович
Правильно ли я понял, что "окрашивание" - это "именование атрибутов" ?

Можно и так сказать. Но это будет несколько неточно. Правильная точка зрения следующая.
Аттрибут есть окрашенный указатель. Есть указатель. Каждый указатель указывает на какойто объект в БД либо на NULL. Если мы говорим о указателях сохраняемых с объектом, то такой указатель имеет уникальный ключ - ключ тоже указатель. Если точнее, то каждый объект Cerebrum это dictionary ключами и значениями которой являются указатели на объекты.

Тоесть аттрибут объекта есть другой объект связанный с данным через какойто поименованный (другим указателем) указатель. Процесс разадресации заключается в получении объекта по указателю-ключу. Причем указатель-ключ может указывать на любой объект БД и получаемый в процессе разадресации объект к разадресуемому указателю прямого отношения не имеет.

Хм. прочел что написал, действительно путано. Будем шлифовать определение в процессе дискуссии. Это то как раз основная цель моего пребывания здесь )))

Теперь расскажу как на основе этого сделать именованные аттрибуты - запросто. В контексте sector cоздаем несколько объектов - по одному на каждый аттрибут. Пусть это будут объекты string с именем аттрибута.

Далее берем любой объект, и в его контексте разадресуем указатель на имя аттрибута, в результате получаем объект не с именем аттрибута, а с значением этого аттрибута.

Чернышев Андрей Леонидович
Вы действительно в реальном проекте будете делать именно так (U-gene так же приводил такой вариант при описании НРМ) или ограничитесь чисто "реляционной" "ссылкой" ("однонаправленной связью" ???) из Договора на Партнера ?

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

Чернышев Андрей Леонидович
И пока я не могу догадаться как Вы будете описывать пример со связью М:М, имеющей собственные характеристики (атрибуты).
Так же как и в РБД - это будет отдельный объект-посредник. Если без доп характеристик (для каждой связи) - то через прямую и инвертированную коллекцию указателей.
31 янв 06, 13:25    [2304986]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Ц4
Guest
автор
Вашу связь - никак. А моя однонаправленная связь итак целостна. Двунаправленная связь - это две однонаправленных. И вовсе не обязательно, что эти две связи должны быть синхронизированны. Возможностью нарушения такой "целостности" я пользуюсь очень часто.

автор
Если вам такое надо - следить за целостностью данной конструкции ваша, как программиста обязанность


А я наивно полагал, что это обязанность СУБД...
31 янв 06, 13:40    [2305090]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Рискну ещё раз
Чернышев Андрей Леонидович
Что значит "скорей всего"
"Скорей всего" означает, что я так сделаю скорей всего. Если же клиент (на месте ктоторого могут быть как объектный навигатор, так и отчётная система или сторонняя информационная система) потребует выдать ответ "одним запросом", я напишу один запрос. Примеры уже писал.
Чернышев Андрей Леонидович
(ведь оба Ваших "запроса" делают одно и то же) ?
Нет, один запрос возвращает список, а другой сумму. Говоря более строгим языком, один запрос возвращает отношение, соответствующее предикату "Список людей из отношения man, вес которых превышает 100", а другой - отношение, сообветсовующее предикату "Суммарный вес людей, весящих более 100".
Чернышев Андрей Леонидович
Ведь Вы уже не раз вычисляли "итоги" вместе с отбором кортежей по условиям в различных приложениях ?
Увы мне, не раз и не два. И что же теперь - голову пеплом посыпать?

Теперь всё же ответьте мне
1) Почему ответ на два вопроса должен быть один?
2) Что конкретно и как вернёт клиенту объектный навигатор? Меня не интересуют технические потроха навигатора, мне интересно ТОЛЬКО ВАШЕ СУГУБО ТЕОРЕТИЧЕСКОЕ МНЕНИЕ. Просто скажите что это будет такое?
31 янв 06, 13:59    [2305207]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Ц4
автор
Если вам такое надо - следить за целостностью данной конструкции ваша, как программиста обязанность


А я наивно полагал, что это обязанность СУБД...

В неопределенном будущем возможна реализация поддержки констрейнтов обрабатываемых СУБД а не business layer. Но если вам интересен перечень недостатков, требующих устранения, так на той же хомепаже перечисленны ограничения текущей версии, гораздо более тяжелые. Модель представления данных Cerebrum еще далека до завершения. Так в первых версиях, в одной "таблице" можно было задавать любое колличество одинаковых "колонок", и объект мог входить в таблицу в качестве ее строки много раз, в текущей версии это уже нельзя (0 или 1 раз), в разрабатываемой в данное время вресии будет еще по другому.
31 янв 06, 14:10    [2305264]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Чернышев Андрей Леонидович
Да, pavelvp, конечно жду ! Напрашиваться не собираюсь.
Почему Вы приглашение то от меня ждёте? :-\
С.Д.Кузнецову было бы интересно ? А эти обсуждения на форуме ему не интересны ? Здесь одни идиоты собрались (я - главный) ?
Я то откуда знаю...
Я ВСЕГДА ГОТОВ СДЕЛАТЬ ДОКЛАД - так и говорю. Возьмите и уступите свое время, если хотите услышать мой доклад.
Ну ни фига себе заявочки... Может Вам ещё и денег дать? Вы уж извините, но своё время я потрачу на свой доклад.
Не хотите, я лично Вам могу сделать доклад. Как видите я совершенно открыт для публичных дискуссий по теории и практике БД, и всегда готов в них участвовать.
Пока не вижу :-)
Так что жду приглашения, и не понимаю что в этом странного.
Прикол, блин... Ну что же Вам сказать - ждите! До посинения :-) А гонору то сколько... Не понятно с чего. Никому не известен. Публикаций нет. Ждёт приглашения.

Умываю руки. Пойду сделаю контрольный выстрел :-)
31 янв 06, 14:32    [2305387]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Насчет GROUP BY не стоило бы с ЧАЛ ом спорить. ИМХО "ORDER BY" - это он просто описАлся.

GROUP BY это SQL, и Дейт действительно пишет, что это нереляционный оператор. Он формирует промежуточный результат, в котором некоторые атрибуты исходного отношения уже сгруппированы, а некторые еще нет (точно не помню, как Дейт это преподносит, но идея именно такая) и это даже не 1 НФ. Другое дело, что GROUP BY формирует промежуточный результат и должен обязательно использоваться с соотвествующими групповыми ф-ями (типа SUM() или FIRST()), выполняемыми над несгруппированными атрибутами. То есть, в конце концов, общий результат этого двусоставного действа является действительно отношением (настолько, насколько таблица SQL близка отношению).

В опреациях РМД есть SUMMАRIZE.
31 янв 06, 15:48    [2305789]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
U-gene - в реализации SQL от IBM нет возможности выполнить GROUP BY без агрегатирующей функции, и другие ограничения тоже наложены, так что результат _успешно_выполненного_ запроса всегда есть корректное отношение, с вполне известной схемой, которую даже можно получить программно, не надо знать заранее (CLI API содержит такие функции, по-моему, это аналог функций ODBC)
31 янв 06, 16:11    [2305915]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Ц4
Guest
[quot shuklin
В неопределенном будущем возможна реализация поддержки констрейнтов обрабатываемых СУБД а не business layer. Но если вам интересен перечень недостатков, требующих устранения, так на той же хомепаже перечисленны ограничения текущей версии, гораздо более тяжелые. Модель представления данных Cerebrum еще далека до завершения. Так в первых версиях, в одной "таблице" можно было задавать любое колличество одинаковых "колонок", и объект мог входить в таблицу в качестве ее строки много раз, в текущей версии это уже нельзя (0 или 1 раз), в разрабатываемой в данное время вресии будет еще по другому.[/quot]

зачем недостатки текущей версии выдавать за концептуальные достоинства?
31 янв 06, 16:11    [2305916]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
Вот это ученый, и не фигнёй страдает, а исследованиями занимается, и результаты его исслудований мы имеем честь применять на практике в туевой хуче коммерческих успешных продуктов.
Можно посмотреть, над чем работал, что сделал, где имплементено.
Это не построитель абстрактной модели сферического коня в вакууме, на основе общей теории и раскрашеных графов. Человек РАБОТАЕТ
Таких на весь IBM всего 53.
31 янв 06, 16:22    [2305974]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ggv
в реализации SQL от IBM нет возможности выполнить GROUP BY без агрегатирующей функции

А что - существуют реализации, где такое возможно?

есть корректное отношение
ИМХО таки таблица, но это мелочи...

В общем то я не и спорю, GROUP BY без агрегирующих функций не бывает(ИМХО), но факт остается фактом - Дейт правда писал, что ..ммм.... сам по себе(?) он реляционным оператором не является.
31 янв 06, 16:36    [2306024]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ЗАМЕЧАНИЕ! 2 ЧАЛ, эти мои замечания не значат, что я стал чего понимать в общей теории или понял как работает нафигатор :) А то Вы опять крутить начнете.....
31 янв 06, 16:41    [2306045]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
U-gene - не знаю, но слышал, что есть базы, где это возможно.
я не встречал, и не пытался запомнить - услышал/прочитал и выкинул из головы.
31 янв 06, 17:10    [2306197]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
U-gene
2 ggv
в реализации SQL от IBM нет возможности выполнить GROUP BY без агрегатирующей функции

А что - существуют реализации, где такое возможно?

Да естественно возможно:
SELECT Field1, Field2
FROM Table1
GROUP BY Field1, Field2
что аналогично
SELECT DISTINCT Field1, Field2
FROM Table1
Уж почему в DB2 это не возможно, для меня это будет загадкой.
31 янв 06, 17:27    [2306296]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ну это же частный случай.
31 янв 06, 17:34    [2306341]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну я не совсем корректно написал, можно и без агрегатирующей функции, как ascrus написал.
парсер пропустит. другое дело, что и без group by такой же результат будет, смысла в group by нет в таком случае.
31 янв 06, 17:42    [2306395]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Проглядел Шуклинскую теорию по http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx
Теоретическое описание в чистом виде вычленить сложно, поскольку постоянно идет путаница физического и логического уровня, то есть то говорит о концепции, то о деталях реализации, короче все в кучу. Конечно, это закономерно, поскольку все мы помним из предыдущих обсуждений, что Шуклин просто не понимает, зачем разделять логический и физический уровни представления, и даже гордится, что он их "спутывает".

Примечание: это странно для человека из мира OO, поскольку одним из главных принципов хорошего ОО-проектирования является абстрагирование, то есть отделение существенного от несущественного, выраженного через инкапсуляцию. Если бы Шуклин хорошо задумался над тем, зачем это нужно в OOA&D, он бы глядишь и допетрил бы, зачем это нужно в технологиях БД.

При попытке оценить теоретическую составляющую, очевидна ее крайнаяя сложность и запутанность. По крайнем мере по сравнению с реляционной теорией. Любой из нас знает, что суть РМД можно строго и практически полно изложить буквально на странице: набор четких определений, основанных на ТМ и логике предикатов. У Шуклина все очень обильно, сложно, неструктурировано. Некоторые базовые термины не определены, к примеру, "таблица" (в математике таблиц нет, в РМД тоже, поэтому суть понятия полностью туманна). Есть и дублирования, и противоречия.

Короче имеем чрезвычайную сложность описания, но бOльшая сложность не означает автоматически преимущества или бOльших возможностей. Это еще надо обосновывать. А до тех пор сложность является явным недостатком.

P.S. Некоторые вещи обосновываются очень странно. К примеру, необходимость "таблиц" объясняется так: "Логично сгруппировать однотипные объекты в таблицы...". Слово "логично" ничего не объясняет, из наличия однотипных объектов вовсе не следует необходимость их группировки в "таблицы".
31 янв 06, 17:47    [2306439]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Да, конечно можно без агрегирующей ф-ии,как ASCRUS написал.
То есть получается, что тотальный GROUP BY (ммм....когда он сам по себе) таки явлется реляционной операцией. :)
Кстати, в SQL результат как раз может быть и не равен исходному. SQL допускает дубликаты строк, а тотальный GROUP BY можно расcматривать как способ избавиться от таких дубликатов.
31 янв 06, 18:11    [2306587]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Ц4
зачем недостатки текущей версии выдавать за концептуальные достоинства?
Вот любим мы чернобелые дихотомии. достоинства и недостатки - вещь относительная. Возьмем к примеру некоторую систему с однонаправленными связями но с возможностью задания констрейнтов. Конечно по сравнению с такой системой у Cerebrum имеется ярковыраженный недостаток - отсутствие таких констрейнтов.

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

Мало того, если копнуть глубже, то в глубине системы с двунаправленными связями можно будет найти либо фуллскан, либо два индекса - что ничем не лучше системы с однонаправленными связями в плане эффективности выполнения запросов.
31 янв 06, 18:36    [2306721]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
mir
Короче имеем чрезвычайную сложность описания, но бOльшая сложность не означает автоматически преимущества или бOльших возможностей. Это еще надо обосновывать. А до тех пор сложность является явным недостатком.

С этим приходится согласится. Впрочем Рим строился не за один день. Сейчас я занят разработкой ядра СУБД а не ее теоретическим обоснованием.

mir
P.S. Некоторые вещи обосновываются очень странно. К примеру, необходимость "таблиц" объясняется так: "Логично сгруппировать однотипные объекты в таблицы...". Слово "логично" ничего не объясняет, из наличия однотипных объектов вовсе не следует необходимость их группировки в "таблицы".


В статье о необходимости речь не шла. Иногда удобно сгруппировать - тогда нужно предоставить возможность такой группировки, а когда не удобно, нужно предоставить возможность работать вовсе без таблиц. В моей СУБД таблицы вещь вторичная. Применять их не обязательно, просто это удобно для группировки объектов с идентичным интерфейсом. Кстати реализация таблиц выполнена на основе API ядра на C# и доступна открыто.
31 янв 06, 18:37    [2306725]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
U-gene
Насчет GROUP BY не стоило бы с ЧАЛ ом спорить. ИМХО "ORDER BY" - это он просто описАлся.

Все-таки здесь он не описался, а привел не ту цитату, т.к. именно ORDER BY не возвращает отношения.
А про GROUP BY действительно у Дейта были рассуждения, насколько я помню, но у него и про "ненужность" значения null есть (и тоже с этим в определенной мере можно согласиться).
31 янв 06, 19:05    [2306860]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
c127
Guest
ggv
ЧАЛ - что надо сделать, чтобы вы навсегда покинули sql.ru ?
Вот просто скажите?
Ну избавьте от своего присутсвия! Окажите любезность!

Не надо, пусть остается. Без ЧАЛ-а будет скучно.
1 фев 06, 02:24    [2307414]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
мод
Guest
mir
Проглядел Шуклинскую теорию

Я то же проглядел и с вашими выводами согласен. Стр-ра данных у него не очень сложная, просто он объяснять не умеет.
Есть "мешок" с "объектами" разных типов а в таблицах хранятся прямые адресные ссылки на этот мешок и на другие таблицы. индексов нет. вообщем спагетти. любая РСУБД решила бы его проблемы значительно проще и эффективнее. ну да ведь хоть плохонькое да свое.
1 фев 06, 09:26    [2307674]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
мод
Есть "мешок" с "объектами" разных типов а в таблицах хранятся прямые адресные ссылки на этот мешок и на другие таблицы. индексов нет. вообщем спагетти. любая РСУБД решила бы его проблемы значительно проще и эффективнее. ну да ведь хоть плохонькое да свое.


Не забываем, что таблицы прилеплены абы було. А основное в Cerebrum как раз этот "мешок" которого то в РСУБД и нету. А сравнивать таблицы Cerebrum (без "мешка") против таблиц РБД действительно смешно. В РБД таблицы находятся чуть ли не на уровне физической реализации, а в Cerebrum они эмулируются на C# (это даже не уровень ядра, а уровень приложения). В Cerebrum таблицы понадобились только для удобства редактирования БД конфигурации и как пример использования ядра.
1 фев 06, 13:03    [2308813]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 39   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить