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

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

Вы так и не поняли. Или сделали вид что не поняли. Ваши статьи - просто треп. Полный аналог разговором старых бабок возле подьезда. Или блондинок о губной помаде :-) . Для того чтобы ваш продукт стал предметом обсуждения необходимо как минимум предоставить результаты его использования и сравнить их с результатами работы аналогов. Пока этого не будет все рассказы и споры о преимуществах и недостатках бессмыслены. Потому что НЕ О ЧЕМ СПОРИТЬ И НЕЧЕГО ОБСУЖДАТЬ.


В такой формулировке я критику принимаю. Вы не хотите тратить свое время на сравнение предложенной мною системы с известными аналогами. Я уважаю ваше время. И по идее должен был бы сам осзаботится проведением таких сравнительных анализов - Ок. Имеет место быть этот недостаток.

Но ведь если нет предмета обсуждения и обсужать нечего, то что вы обсуждаете? Просто бы пролистали статью и забыли через секунду о том что листали пустое место. Ан нет, критикуете, позорите - значит зацепило )))
6 янв 06, 17:33    [2233057]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Попробую сделать краткие, возможно промежуточные, выводы из состоявшейся выше дискуссии. Шуточное название темы фактически отражало попытку проверить SQL на прочность. Для ударов, точнее сравнения, использовался язык Zigzag. Лично для меня трещин в SQL оказалось значительно больше чем в Zigzag. Начиная от мелких неоднозначностей в разных диалектах SQL, и кончая крупными трещинами. Примером последних является ограниченная структурная выразительность для представления иерархически-связанных данных (от которых нам никуда не уйти и которые мы изучали даже в школе на примере класса животных). Эта ограниченность не рассматривалась в топике, но думаю очевидна для всех. Другой трещиной, точнее ограничением SQL на фоне Zigzag, является жесткая привязанность к таблицам через FROM и предопределенность имен атрибутов. По сути интерактивным язык SQL можно назвать с большой натяжкой, так как пользователь для формулировки запроса должен заранее четко знать имена таблиц и столбцов. У Zigzag обнаружились также преимущества связанные с динамической структурой данных и автоматическим контролем целостности. Разумеется все это ИМХО.

Главный недостаток Zigzag, это функциональная выразительность. Обязательно ли ее нужно добавлять в язык СУБД, если он (кстати как и SQL) базируется на более мощных языках программирования? Вспомним историю. Язык СУБД dBase не уступал тогдашним языкам программирования. В нем присутствовали структурные операции (условия, циклы). Разработчики SQL отказались от структурных операций, зато сосредоточили больше внимания чисто СУБД-шным задачам, быстродействие, целостность и динамичность структуры, запросная выразительность. В Zigzag этим задачам уделено еще большое значение. Zigzag, это язык алгебры, причем максимально приближенной к внутренним особенностям реализации. Разработчики Zigzag отказались от реализации механизма исчисления как в SQL. Кстати, итерация рассмотренная ранее в топике и связанная с выводом данных, может быть представлена через Java-цикл без какой-либо потери в быстродействии.
10 янв 06, 12:29    [2239194]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
Лично для меня трещин в SQL оказалось значительно больше чем в Zigzag. Начиная от мелких неоднозначностей в разных диалектах SQL, и кончая крупными трещинами. Примером последних является ограниченная структурная выразительность для представления иерархически-связанных данных .


Ну до мелких неоднозначностей в разных диалектах Zigzag-у еще надо дорасти, а вот про структурную выразительность для представления иерархически-связанных данных давайте чуть поподробней.

Допустим у нас есть некая иерархическая структура: сотрудник, его заплата, его начальник. У начальника естественно тоже может быть начальник. Надо узнать сколько какой начальник получает с его подчинёнными. Как это делается на SQL мы знаем - невыразительно. Покажите нам как же эта ограниченность структурной выразительности для представления иерархически-связанных данных преодолена в Zigzag-е


vadiminfo и shuklin - прошу вас в этом топике больше не выяснять отношений
10 янв 06, 13:05    [2239461]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
УРА товарищи!!!

2 okdoky
:)Тока объясните мне, почему бедного пользоватяля надо нагружать еще и знанием имен атрибутов?

Ладно...что делать , когда есть таблица "Директора" и "Артикулы" содержащие одинаковый атрибут "Имя"? А вдруг есть еще терья таблица с таким же атрибутом? Запустит пользователь запрос без FROM - как он узнает, откуда взялись значения? Дык что же получается, что пользователь таки должен знать имена атрибутов каждой таблицы?

Ах да.... у нас имена атрибутов тоже не предопределны.... Я не пойму... имена атрибутов не предопределны, а именами таблиц пользоваться не нужно....И как мне теперь быть? Или я должен думать для каких имен атрибутов имена таблиц указывать, акакие и так сойдут?

И пожалуйста, если Вас не затруднит, расскажите(хотя бы на пальцах), где в SQL алгебра и исчисление, какое отношение они имеет к итерациям, и как может быть алгебра приближена к внутренним особенностям реализации... а то возникает впечатлнеи, что Вы всю эту реляционщину a'la Excel воспринимаете....

SergSuper
vadiminfo и shuklin - прошу вас в этом топике больше не выяснять отношений
+100:)
10 янв 06, 13:23    [2239545]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

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

Для ударов, точнее сравнения, использовался язык Zigzag.

Проблема в том, что SQL выдержал конкуренцию с более продвинутыми языками. А Вы хотите с каким-то там Zigzag его сравнить. Смешно - чес слово.


okdoky

Примером последних является ограниченная структурная выразительность для представления иерархически-связанных данных (от которых нам никуда не уйти и которые мы изучали даже в школе на примере класса животных).

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

okdoky

Другой трещиной, точнее ограничением SQL на фоне Zigzag, является жесткая привязанность к таблицам через FROM и предопределенность имен атрибутов.

Есть понятие динамического SQL. Вы уверены, что в курсе про все возможности SQL в СУБД?

А по теме - пока Zigzag не окажется языком хоть одной продвинутой СУБД типа Скуля, Оракла, DB2, Sybase, он заведомо будет хуже. Без единого шанса.
Поэтому Вам лучше этих парней сагитировать. А нас можно тока развести на него, чтобы мы завалили проект раз и на всегда, хотя и зигзагообразно.
10 янв 06, 13:47    [2239630]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Попробую сделать краткие, возможно промежуточные, выводы из состоявшейся выше дискуссии.
Вы ведь сделали ряд громких заявлений, но даже приблизительно не обосновали ни одно. Выходит, итог один: вы никого не убедили, ваша позиция слаба. Других итогов пока нет.
okdoky
Для ударов, точнее сравнения, использовался язык Zigzag. Лично для меня трещин в SQL оказалось значительно больше чем в Zigzag.
Для сравнения надо знать сравниваемое. По ряду моментов выяснилось, что вы SQL знаете крайне поверхностно. Так может надо было сначала подучить матчасть, а потом с вескими аргументами в руках уж и спорить? Впрочем, глубокое освоение предмета возможно вовсе отбило бы у вас охоту спорить, так часто бывает.
okdoky
Начиная от мелких неоднозначностей в разных диалектах SQL
Пока вся история программирования показывает лишь одно: любой популярный язык несмотря на все стандарты быстро обрастает диалектами. Это в определенной мере даже показатель популярности языка. Отсутствие, скажем, у языка Zigzag диалектов говорит явно о том, что он просто мало распространен. Не больше и не меньше.
okdoky
и кончая крупными трещинами. Примером последних является ограниченная структурная выразительность для представления иерархически-связанных данных (от которых нам никуда не уйти и которые мы изучали даже в школе на примере класса животных). Эта ограниченность не рассматривалась в топике, но думаю очевидна для всех.
Вовсе не так очевидна, как вам кажется. Проблема здесь есть, но ее осмысление давно ведется. Не думаю, что вы в курсе хотя бы постановок возможных задача и предлагаемых способов решений. Об этом говорит фраза про «структурная выразительность». Вещь туманная. Вы о какой выразительности-то хоть говорите, на каком уровне представления? Понимаете, о чем я? Если пока нет, вам пора обратно за парту (фигурально).
okdoky
Другой трещиной, точнее ограничением SQL на фоне Zigzag, является жесткая привязанность к таблицам через FROM и предопределенность имен атрибутов.
Путаница «зоны ответственности» языка БД и модели данных. Если модель данных — реляционная, то и язык манипулирует отношениями. Предопределенность имен атрибутов также черта модели данных, любой язык РБД обязан это поддерживать.

У вас главная путаница в «критике» проистекает от того, что вы, во-первых, модель данных как таковую от конкретного языка данных не отличаете, а во-вторых, саму РМД толком не знаете. Тут бы теорию подучить не мешало, книги бы почитать.
okdoky
У Zigzag обнаружились также преимущества связанные с динамической структурой данных и автоматическим контролем целостности.
Где же это в дискуссии они обнаружились? Или они обнаружились исключительно у вас в голове, в тайне от нас? К чему все эти бездоказательные заявления? Перестаньте, наконец, декларировать, начните обосновывать. И еще, о каком контроле целостности в Zigzag может идти речь, если в нем даже предопределенная типизация атрибутов не поддерживается (как вы сами признали)? А ведь строгая типизация есть первый и главнейший вид автоматического контроля целостности.
okdoky
Главный недостаток Zigzag, это функциональная выразительность.
Нет такого понятия «функциональная выразительность». Что вы все время придумываете какие-то псевдонаучные термины? Есть функциональные возможности. Гадать, что вы понимаете под «функциональной выразительностью», нет никакого желания.
okdoky
Zigzag, это язык алгебры
Опа, а вот тут поподробнее. Язык какой именно алгебры? Не реляционной, это точно. Итак, первое, над какими элементами замкнута алгебра, реализуемая в Zigzag? Второе, каков хотя бы один базис операций?
okdoky
Разработчики Zigzag отказались от реализации механизма исчисления как в SQL.
Что такое за зверь «механизм исчисления»? Очередная ваша придумка? Есть реляционное исчисление, но SQL однозначно признается языком реляционной алгебры с элементами реляционного исчисления. От чего там эти разработчики отказались, скрыто мраком тайны.
10 янв 06, 16:55    [2240743]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir: Согласен, что многие использованные мною выражения типа "структурная выразительность" достаточно расплывчаты. Во многом они опираются на контекст. Участие в форуме требует времени, приходится сокращать. Очевидно, вам трудно понять из-за недостаточной включенности в предыдущий диалог и разумеется из-за большого мусора. Предлагаю вам просто не читать реплики, связанные с shuklin. О контроле целостности речь действительно шла. Согласен, что эта характеристика Zigzag не является характерной для всех ООСУБД или ОРСУБД. Хотя вы знаете, что в языках программирования удаление класса обычно сопровождается ошибкой при компиляции других классов, в которых этот класс упоминается. Я не хочу давать четкое определение понятий "исчисление" или "алгебра". Лучше и понятнее это будет на примерах (хоть и расплывчатых).
Предположим в Zigzag заданы 2 множественные переменные $x и $y.
Операция пересечения множеств будет выглядеть так =[$x=$y],
объединения =[$x,$y],
разности =[$x~$y].
Как это выражается в SQL? Через WHERE … AND OR NOT?

SergSuper
Допустим у нас есть некая иерархическая структура: сотрудник, его заплата, его начальник. У начальника естественно тоже может быть начальник. Надо узнать сколько какой начальник получает с его подчинёнными.
Эта задача не требует иерархической зависимости, в частности наследования атрибутов. Вы заманиваете меня в табличные SQL-сети? Я реально боюсь, что SQL будет смотреться лучше, чем цикл в Java/Zigzag для таблицы
сотрудник; зарплата; начальник
Петров ; 400; Злюкин
Иванов ; 300; Злюкин
Злюкин ; 600; Смотренко
Смотренко; 1000

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

Понять его не сложно, если вы знаете значения символов : и (). Они легко переводятся на ЕЯ:
a: - a NAMELY SOMETHING (или CLASS a)
:b - SOMETHING NAMELY b (или CLASS WITH b)
(b) - SOMETHING OF b (или RELATION OF b)
Фактически мы определили такую иерархическую зависимость:
сотрудник:1:2:[3,4]. Ответ будет таким (реально проверил):
имя; зарплата
Смотренко; 1000
Злюкин; 600
Иванов; 300
Петров; 400
10 янв 06, 19:58    [2241379]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
okdoky
Member

Откуда:
Сообщений: 349
=a(b,c) переводится: a OF b AND c
=a([b,c]) переводится: a OF b OR c
=a(b)~(c) переводится: a OF b AND NO OF c
Сложные конструкции лучше не переводить :)
10 янв 06, 20:06    [2241391]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
тлгдшлщм
Guest
okdoky
Читайте стандарт SQL.
Union, Intersect, and Except
10 янв 06, 20:35    [2241436]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
okdoky
Member

Откуда:
Сообщений: 349
тлгдшлщм
Да, я действительно не учел, что можно использовать выражение типа
SELECT * FROM R1
INTERSECT
SELECT * FROM R2

Признаю расплывчатость своих формулировок. И все же, чему это выражение больше соответствует языку алгебры или исчисления? По-моему здесь какая-то смесь. Ведь SELECT по сути отражает тот самый "механизм исчисления" и может быть выражен например так
{ r | r Є R }

В алгебре тоже пересечение выглядит на много компактнее
R = R1 INTERSECT R2
где на месте R1 и R2 могут использоваться переменные. Сравните Zigzag выражение
$R1 = [$R1=$R2]

Какой язык ближе к алгебре? Впрочем, я действительно многое в SQL не знаю, поэтому и участвую в форуме…. Можно ли в SQL пересечение задать проще?
10 янв 06, 22:36    [2241618]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 okdoky
Ну Вы даете. Алгебра не определяется представлениями - т.е. тем как что-то там выглядит. Она определяется алгебраическими операциями: т.е. грубо говоря ф-ями, у которых аргументы и значения, которые они возвращают принадлежат одному и тому же множеству. В частности, в рел алгебре это множество отношений. Проще говоря в запросах участвуют отношения и возвращают они тоже отношение, а не число, массив или еще что.
Один SELECT - это унарная операция выбора (даже если ниче не выбрали).
SELECT * FROM R1
INTERSECT
SELECT * FROM R2
Последовательность алгебр операций - две унарные и теор мн пересечение.
А то как это выглядит - вопрос представления. В данном случае максимально приближенное к естественному языку - выбрать оттуда то и оттуда-то и тока те что совпадают в обоих.

Или Вы думаете, что если будете придумывать новые истолкования алгебре, исчислению и проч, то можно все запутать и это поможет Зигзагу? Ведь Зигзаг звучит как запутывание?

А Шаклин между прочим, как и Вы проталкивает левые весчи на хорошо занятые позиции. Так что он Вам товарисч в этом смысле. Вам бы объедениться с ним, а Вы от него отгораживаетесь опрометчиво.
10 янв 06, 23:31    [2241664]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Александр Гoлдун
Member

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

Впрочем, я действительно многое в SQL не знаю, поэтому и участвую в форуме….

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

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

"Попытка проверить SQL на прочность" ;)
Если гнуть пальцы, то только не с таким багажом знаний и опытом, иначе пообломают. Нет ничего зазорного в том, что чего-то не знаешь. Учиться никогда не поздно. Но начинать это, накидав понтов на пустом месте, мягко говоря странновато.

Ладно, вот тебе в помощь для начала. Классика: Мартин Грабер. SQL
11 янв 06, 00:39    [2241722]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
mir: Согласен, что многие использованные мною выражения типа "структурная выразительность" достаточно расплывчаты. Во многом они опираются на контекст.
Тогда не надо их использовать. Отсылка к контексту не поможет никому, ибо сам контекст у вас очень смутен. Короче, давно сказано: кто ясно мыслит, тот ясно излагает.
okdoky
Участие в форуме требует времени, приходится сокращать.
Может, вам кто-то нож к горлу приставил, дескать, а ну создай тему в это форуме? Нет времени — не пишите. А если пишете, то уделяйте время.
okdoky
Очевидно, вам трудно понять из-за недостаточной включенности в предыдущий диалог и разумеется из-за большого мусора.
Я полностью прочитал весь диалог и включен в него не меньше других.
okdoky
О контроле целостности речь действительно шла. Согласен, что эта характеристика Zigzag не является характерной для всех ООСУБД или ОРСУБД. Хотя вы знаете, что в языках программирования удаление класса обычно сопровождается ошибкой при компиляции других классов, в которых этот класс упоминается.
Какая характеристика Zigzag «не является характерной…»? Контроль целостности? Так в Zigzag нет даже типизации, о какой целостности вообще тогда речь?. Про удалении класса вообще не понял, при чем здесь это?
okdoky
Я не хочу давать четкое определение понятий "исчисление" или "алгебра".
Может, просто не знаете? Впрочем, определений никто не просил. Читайте внимательнее, повторю: «первое, над какими элементами замкнута алгебра, реализуемая в Zigzag? Второе, каков хотя бы один базис операций?»
okdoky
Операция пересечения множеств будет выглядеть так =[$x=$y], объединения =[$x,$y], разности =[$x~$y].
Хорошо, что эти три операции поддерживаются, это плюс. Однако проектировщика языка штрафовали за каждый лишний символ, видимо. Очень ненаглядно и очень неинтуитивно. Знак равенства вовсе не ассоциируется у людей с объединением, он ассоциируется с равенством (неожиданно, правда?) Знак тильда для разности? Это просто супер-очевидно :). Почему хотя бы не минус? А почему запятая — это объединение, а не, скажем, соединение? [Тяжкий вздох] Короче, я уже говорил: слова понятнее знаков, если только знаки не используются в общепринятом математическом смысле (или хотя бы в общепринятом «программистском» смысле).
Ну, и еще вопросы: поддерживаются ли R-операции проекции, соединения, расширения, переименования, группировки (ах да, эта точно нет, уже обсуждали)?
Составные выражения произвольной сложности поддерживаются?
okdoky
тлгдшлщм
Да, я действительно не учел, что можно использовать выражение типа
SELECT * FROM R1
INTERSECT
SELECT * FROM R2
Признаю расплывчатость своих формулировок. И все же, чему это выражение больше соответствует языку алгебры или исчисления? По-моему здесь какая-то смесь. Ведь SELECT по сути отражает тот самый "механизм исчисления" и может быть выражен например так
{ r | r Є R }
В алгебре тоже пересечение выглядит на много компактнее
R = R1 INTERSECT R2
где на месте R1 и R2 могут использоваться переменные. Сравните Zigzag выражение
$R1 = [$R1=$R2]
Какой язык ближе к алгебре? Впрочем, я действительно многое в SQL не знаю, поэтому и участвую в форуме…. Можно ли в SQL пересечение задать проще?
Зачем тогда рассуждать о высоких материях, об алгебрах и исчислениях, если вы тут путаетесь? Пролью чуток света: в SQL элементами R-исчисления являются кванторы EXISTS, ANY, SOME. Практически все остальное от R-алгебры. Речь, конечно, о DML.
Ну и крайне странно видеть рассуждения о «близости» языка к алгебре по критерию «компактности». Это уже за пределами моего понимания.
11 янв 06, 07:35    [2241904]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky

SergSuper
Допустим у нас есть некая иерархическая структура: сотрудник, его заплата, его начальник. У начальника естественно тоже может быть начальник. Надо узнать сколько какой начальник получает с его подчинёнными.
Эта задача не требует иерархической зависимости, в частности наследования атрибутов. Вы заманиваете меня в табличные SQL-сети?

Я специально не упоминал слова "таблица". Так что Вы сами туда впутываетесь :)
Кстати: что такое по Вашему иерархическая зависимость? По-моему к наследованию аттрибутов она никакого отношения не имеет.
okdoky

Я реально боюсь, что SQL будет смотреться лучше, чем цикл в Java/Zigzag для таблицы

Ну дык продемонстрируйте хоть что-то где Zigzag будет смотреться лучше - хоть посмотреть бы на эту стуктурную выразительность. А то получается как в старом анекдоте:
- Вы любите Ленинградское телевидение?
- Люблю. Смотреть - нет, а так люблю.

okdoky

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

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

Понять его не сложно, если вы знаете значения символов : и (). Они легко переводятся на ЕЯ:
a: - a NAMELY SOMETHING (или CLASS a)
:b - SOMETHING NAMELY b (или CLASS WITH b)
(b) - SOMETHING OF b (или RELATION OF b)
Фактически мы определили такую иерархическую зависимость:
сотрудник:1:2:[3,4]. Ответ будет таким (реально проверил):
имя; зарплата
Смотренко; 1000
Злюкин; 600
Иванов; 300
Петров; 400

т.е. это Вы написали типа запрос
select имя, зарплата from сотрудник
Но я то просил узнать сколько какой начальник получает с его подчинёнными. Т.е. например у Злюкина должно быть 1300
11 янв 06, 10:29    [2242304]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
AlexTheRaven
Member

Откуда: Москва
Сообщений: 879
shuklin
Да необходимо переходить с РБД на ОРБД либо на ООБД.

А что Вы думаете о моделях
EAV
Тенцера
модифицированной (Змеевым и Моисеевым) модели Тенцера?

Они замечательно реализуются на базе реляционной модели, которая, согласитесь, в некоторых существующих СУБД неплохо реализована. И при этом позволяют делать почти то же, что и ОРБД-ООБД (хранить изменчивые объекты предметной области), но предсказуемо, стандартно и масштабируемо.
11 янв 06, 13:42    [2243510]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mv
Member

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

А что Вы думаете о моделях
EAV
Тенцера
модифицированной (Змеевым и Моисеевым) модели Тенцера?

Они замечательно реализуются на базе реляционной модели...

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

AlexTheRaven

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

... какой коварный переход от одной мысли к другой!

AlexTheRaven
...но предсказуемо, стандартно и масштабируемо.

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

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

Хотя возможности ООСУБД растут . (Это я насчет объемов).

А зачем вообще их использовать, это ООСУБД? Проще потомучто.
11 янв 06, 14:46    [2243825]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
AlexTheRaven
shuklin
Да необходимо переходить с РБД на ОРБД либо на ООБД.

А что Вы думаете о моделях
EAV
Тенцера
модифицированной (Змеевым и Моисеевым) модели Тенцера?


Вот еще подобная EAV модель http://www.microsoft.ru/offext/details.aspx?id=620 но моего авторства.

Тяжело работать с этим всем в реальной жизни. ИМХО лучше модель "SharePoint" тогда взять, если ограничением является обязательное использование РБД. Ну а если такого требования нет - то ОБД хорошая альтернатива.
11 янв 06, 15:32    [2244050]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mv
Member

Откуда:
Сообщений: 8876
shuklin
... если ограничением является обязательное использование РБД. Ну а если такого требования нет - то ОБД хорошая альтернатива.


Вообще, странное обсуждение.
"Почему не использовать ОБД?"
Ответ (в переводе):
"Потому что мы не знаем, что это такое, и не морочьте голову!"
11 янв 06, 15:37    [2244079]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
AlexTheRaven
Member

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

Они [EAV и её производные] предсказуемо загибаются под небольшой (это насчет масштабируемости) нагрузкой.
Если почитать внимательнее описание моделей - то там никто этого и не скрывает.


Там да. А в жизни... Поправьте меня, если неправ, но большинство учётных программ и ERP-систем, и даже SAP R/3, используют эти модели, а нагрузки там немаленькие... Хотя, конечно, особенно хитрых наследований и связей там нет (да и в реальном мире их не так уж много).

mv

Вообще, странное обсуждение.
"Почему не использовать ОБД?"
Ответ (в переводе):
"Потому что мы не знаем, что это такое, и не морочьте голову!"


Не только и не столько потому, что не знаем. Скорее уж потому, что не хочется быть зависимым от производителя, хочется иметь несколько более-менее взаимозаменяемых альтернатив при выборе, часть из которых - бесплатные. И ещё хочется иметь стандарт.
11 янв 06, 16:37    [2244465]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
AlexTheRaven
Member

Откуда: Москва
Сообщений: 879
AlexTheRaven
(да и в реальном мире их не так уж много)

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

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

AlexTheRaven

Не только и не столько потому, что не знаем.


Попробовать - слабо? Сил и средств потребуется минимум.

AlexTheRaven

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

Фантастика.

Есть отличные примеры по поводу "взаимозаменяемости". Например, BDE от
Borland. Даже вспоминать неприятно.

AlexTheRaven

.... часть из которых - бесплатные.

...их есть!


AlexTheRaven

И ещё хочется иметь стандарт.


Ну, ладно. С этим ничего не попишешь. Против своих желаний идти - последнее
дело.
Э... а спецификации OMG group устроят?
Или нужен государственный промышленный стандарт?
А можно узнать, зачем?
А по-простому - чтобы быстро работать - не хочется?
А нельзя выкрутиться, написав небольшой класс - (facade - template), и
тешить руководство (я уверен, что этот бред насчет стандарта не Ваш лично -
Вы же профессинал, Вам работать нужно! - ... или нет?) тем, что если не
устроит производительность/надежность/масштабируемость, то легко можно будет
перейти к другому продукту, написав "прокладку" к нему? (Я сам не верю в
то, что говорю - но мы-то с Вами, понимем, о чем речь ;-) )
---------------------------------------------------------------------------
Ну почему никто не задаст вопрос - что, как, где?

Posted via ActualForum NNTP Server 1.3

11 янв 06, 21:15    [2245439]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
okdoky


SELECT * FROM R1
INTERSECT
SELECT * FROM R2

В алгебре тоже пересечение выглядит на много компактнее
R = R1 INTERSECT R2
где на месте R1 и R2 могут использоваться переменные. Сравните Zigzag выражение
$R1 = [$R1=$R2]

Какой язык ближе к алгебре? …. Можно ли в SQL пересечение задать проще?
Языки программирования развиваются от трудночитаемых (типа ассемблера) в направлении к более близким к человеческому языку. FORTRAN был первым прорывом, и он позволял писать сразу формулы, вместо машинных команд. SQL организован так, что его операторы имеют практически дословный перевод на английский язык. это видно и по оператору выше: "выбрать все из R1 и сделать пересечение с выборкой всего из R2". Гораздо понятнее чем "$R1 = [$R1=$R2]". Желание вернуться к закорючкам, в наше время, вообще не к месту.

okdoky
Другой трещиной, точнее ограничением SQL на фоне Zigzag, является жесткая привязанность к таблицам через FROM
в порядке легкого флейма, в форуме по физике это бы звучало примерно так: "максимально возможная скорость - скорость света?! не может быть, это такое ограничение!"
11 янв 06, 22:27    [2245534]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mv
Member

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

shuklin

Тут приходит некто и начинает впаривать народу о том, что скоро РБД умрут,
что в связи с этим, все знания этой туссовки - фуфло и что в скором от этой
ЗП останется пшик и придется всем кто будет в состоянии (а ведь не все
будут) переучиваться на ОБД.


Самое интересное - что тут нехрен переучиваться ( Больше разговоров,
чем проблем. )
....
Нам хлеба не нужно - нам работу давай!...

Posted via ActualForum NNTP Server 1.3

12 янв 06, 05:21    [2245861]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
mv
А по-простому - чтобы быстро работать - не хочется?
А нельзя выкрутиться, написав небольшой класс - (facade - template), и
тешить руководство (я уверен, что этот бред насчет стандарта не Ваш лично -
Вы же профессинал, Вам работать нужно! - ... или нет?) тем, что если не
устроит производительность/надежность/масштабируемость, то легко можно будет

Ну по первых в том то и дело, что у ООБД производительность пока не на высоте в тех местах, где идут обработки множеств. Во вторых - лично я вот не хочу писать небольшие или большие классы, я вообще стараюсь избегать кодинга там, где его можно избежать и здесь SQL и РСУБД мне здорово в этом помогают - я только описываю схему БД и запросами говорю "что делать", а вот "как делать", это уже не моя головная боль. Отсюда для меня и неудобства ООБД или Cache - там все равно придется думать, "как делать" и заниматся кодингом. Да и вообще лично у меня давно об ООП сложилось стойкое мнение за все 15 лет общения с ним - пока проекты не сложные и тяжелые, ООП выглядит просто блестяще и бесподобно. Как только проекты начинают расти, ООП в конце концов оказывается самым главным тормозом как в разработке кода, так и производительности решений - для сложных решений уже получаются не иерархии классов, а целые запутанные сети связей, событийная модель оказывается гораздо хитрее отладчика, поиск ошибок превращается в увлекательную игру - "угадай, откуда был вызов" и т.д. и т.п. Мне кажется поэтому то все начинают с ООП, пишут мелкие проекты и радуются как все быстро и хорошо. Как только приходит опыт и сложные проекты, обычно приходит и понимание, что ООП для хранения и обработки данных никуда не годится
mv
А по-простому - чтобы быстро работать - не хочется?
А нельзя выкрутиться, написав небольшой класс - (facade - template), и
тешить руководство (я уверен, что этот бред насчет стандарта не Ваш лично -
Вы же профессинал, Вам работать нужно! - ... или нет?) тем, что если не
устроит производительность/надежность/масштабируемость, то легко можно будет

Ну по первых в том то и дело, что у ООБД производительность пока не на высоте в тех местах, где идут обработки множеств. Во вторых - лично я вот не хочу писать небольшие или большие классы, я вообще стараюсь избегать кодинга там, где его можно избежать и здесь SQL и РСУБД мне здорово в этом помогают - я только описываю схему БД и запросами говорю "что делать", а вот "как делать", это уже не моя головная боль. Отсюда для меня и неудобства ООБД или Cache - там все равно придется думать, "как делать" и заниматся кодингом. Да и вообще лично у меня давно об ООП сложилось стойкое мнение за все 15 лет общения с ним - пока проекты не сложные и тяжелые, ООП выглядит просто блестяще и бесподобно. Как только проекты начинают расти, ООП в конце концов оказывается самым главным тормозом как в разработке кода, так и производительности решений - для сложных решений уже получаются не иерархии классов, а целые запутанные сети связей, событийная модель оказывается гораздо хитрее отладчика, поиск ошибок превращается в увлекательную игру - "угадай, откуда был вызов" и т.д. и т.п. Мне кажется поэтому то все начинают с ООП, пишут мелкие проекты и радуются как все быстро и хорошо. Как только приходит опыт и сложные проекты, приходит и понимание, что ООП для хранения и обработки данных никуда не годится.
12 янв 06, 06:55    [2245893]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Гм, как это оно сдублировало так интересно ?
12 янв 06, 06:56    [2245894]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 39   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить