Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
mir
AlexKB
Павел Воронцов
AlexKB
Где-то это все напоминает коробки и стеллажи с перфокартами.
Просто у Вас бедная фантазия.


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

верите или нет
но мампсисты тоже в основном не перебирают,
а только лишь иногда - если очень надо.
Существуют готовые блоки быстрого перебора
написаные и провереные, и надо лишь правильно оформить запрос,
а как они там работают - их сугубо унутренее дело.
То есть мы работаем в основном как все нормальные люди.
Как Вы.
Но если надо ...... если Родина прикажет ...
вот тогда мумпсист залезет в mumps-код и на уровне атомов
сделает то, что и не снилось никакому оптимизатору.
Мумпсист может сделать ВСЕ
(если надо)
но под пиво..
14 мар 06, 17:08    [2447391]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
да как уже говорилось неоднократно, вопрос не в том, что можно сделать все.
Вопрос в стоимости такого "можно все"
Как только потребуется выполнить запрос, под выполнение которого не предназначена текущая модель данных, придется переделывать эту модель со всеми вытекающими.
В этой же теме это неоднократно указывалось.
14 мар 06, 17:15    [2447443]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
ggv
да как уже говорилось неоднократно, вопрос не в том, что можно сделать все.
Вопрос в стоимости такого "можно все"
Как только потребуется выполнить запрос, под выполнение которого не предназначена текущая модель данных, придется переделывать эту модель со всеми вытекающими.
В этой же теме это неоднократно указывалось.

>вопрос не в том, что можно сделать все
Достаточная универсальность или "возможность сделать все" является первоопределяющим при выборе системы и прежде всего языка программирования. SQL хорош только как дополнение к PL или Java.
>Вопрос в стоимости такого "можно все"
Вы имеете ввиду стоимость переделок, изменения модели? Как раз универсальность дает больше возможности для изменения, в том числе для развития и усовершенствования. С узкоориентированными языками даже самого высокого уровня Вы далеко не уедете.
14 мар 06, 18:14    [2447773]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
А мне кажется, что это Вы не поняли главного, SergSuper. И что интересно, Вы же сами изначально интересовались как решаются подобные задачи. Как имея в БД данные и условия (они же тоже должны быть в БД !), решать подобные задачи. А Вы говорите "тупо переписал". А как же Вы будете делать производственное планирование, например ? "Тупо переписывать" ?
Понятно, что "эвристика", все-таки, есть в самом разбиении условий по мощности. Явная привязка "жильца" к дому (или технологической операции к станку) мощнее, чем "соседство". Но это, честно признаюсь, не я придумал (так что у меня нисколько не ушло времени на алгоритм).

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

мод решил поиздеваться над "мампсистами". Можно еще 100 раз написать

^сущность(ид. сущности, ид. свойства)=значение свойства
или
^сущность(ид. сущности)=свойства сущности
(так по умолчанию в Cache, но тогда получается какое-никакое ограничение на количество свойств)

а он все равно будет спрашивать про табличку и поля.
14 мар 06, 20:53    [2448260]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Достаточная универсальность или "возможность сделать все" является первоопределяющим при выборе системы и прежде всего языка программирования.

Ассемблер форева!

okdoky

SQL хорош только как дополнение к PL или Java.

Заключение, которму позавидует любой эксперт. Наверное, чтобы такие делать нуно быть акадэмиком от компьютерных наук. Не меньше.

okdoky

Как раз универсальность дает больше возможности для изменения, в том числе для развития и усовершенствования. С узкоориентированными языками даже самого высокого уровня Вы далеко не уедете.

И хде Вы - учредители премии Тьюринга?! Правда многие уже далеко уехали, но не с узкоориентированными, а специализированными языками БД. И уж точно с SQL. А вот насчет Зигзага прогноз верен. Он и как язык БД плох, ну и как дополнение к Джаве вроде совсем не нужен. Она и без него обойдется.
14 мар 06, 20:55    [2448263]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
ну я
SergSuper
AlexKB
// методом прямого доступа к данным только что заполненной таблицы
// выводим их в компонент таблица
for i=1:1:4
{do ..StringGrid1.SetRowCells(i,$list(^Test.PiliD(i),1,4))}

Стоп - какой StringGrid? это всё выполняется на клиенте?

Судя по идентификаторам и формату вызова речь идет о smwrap.
Работает на сервере. do ..StringGrid1.SetRowCells отправляет команду клиенту. Клиент отрабатывает (в данном случае изменение строки).
Непривычность состоит в том, что в традиционных клиентах к sql клиент запрашивает сервер для получения данных, а в данном случае сервер управляет клиентом, указывая что с каким контролом делать.

Клиент, обрабатывающий команду уже не клиент, а сервер. И сервер уже не сервер, а клиент.
Клиент-сервер архитектура завоевала рынок не потому что кому-то захотелось чтоб один кусок программы запросы всегда обрабатывал, а другие куски их всегда посылали, а потому что никакая другая архитектура реально так эффективно и надежно существующие сегодня на рынке задачи решать не может. Это не чья-то злая воля или каприз, а результат совершенно равноправного естетсвенного отбора. Управление клиентом из сервера не используется не потому, что никто не подозревает, как это удобно, а потому, что так уже много раз попробовали, убедились что ведет к проблемам и перешли на клиент-сервер.

MX -- ALEX
c127
MX -- ALEX

хотя конечно это дело удобства-неудобства модели,

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

нам повезло что мы этого не знали -
поэтому запросто вдвоем заавтоматизировали на MUMPS
несколько крупных заводов и сотню мелких-средних :)

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

Я задал конкретные вопросы, почему бы на них не ответить? Например по индексам, которые в М то появляются, то пропадают. https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=19#2437781

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

Не лучше ли ответить на вопросы, а потом приводить следующий, если будет желание. Или в крайнем случае приводить пример с постановкой задачи, а это совсем не не то же самое что комментарии в коде.
15 мар 06, 00:38    [2448734]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
ораклоидальный мампсист
мод решил поиздеваться над "мампсистами". Можно еще 100 раз написать

^сущность(ид. сущности, ид. свойства)=значение свойства
или
^сущность(ид. сущности)=свойства сущности

ОК пошел предметный разговор
в случае 1 получается индекс по (ид. сущности, ид. свойства) а индексируются <значения свойства> (то же EAV). Сразу вопрос: как искать по значению ? только full scan ?
в случае 2 <свойства сущности> - это позиционная строка знаков через разделитель ? (если так то не катит !) и тот же вопрос как искать по значению ?
15 мар 06, 09:42    [2449201]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127

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


он что - гавно не в ту сторону качал ?
или немецкий газ на Украину отправлял ?

на нормальном производстве НЕТ хреново работающих
насосов из-за того что они написаны на перле.
Если подшипник заклинило - другое дело.
Но тогда вряд ли даже SQL-насос справится

Вам бы поработать не мешало.
С насосами.

Кстати наши системы автоматического взвешивания- регистрации
железнодорожных грузов прошли все нужные и ненужные аттестации
и работают уже лет 7 в круглосуточном режиме
- ни единого сбоя или нарекания.

на MUMPS.
============================
15 мар 06, 09:46    [2449215]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость...
Guest
Товарисч непоял. Насос то работаит! это драйвир не работаит. Хотя как верна замечена, падшипнику эта не поможит. А то, что существует работающая МУМПС система - это наверное главный аргумент, гаварщий, что МУМПС круче СКУЛЯ? Кстати - а как эта памагло падшипнику??? Давайте типерь пример на МУМПСе, с кодом каторый памагает падшипнику, и папрасите сделать аналог в SQL ГЫ-ГЫ. Тагда ани точно сальют.

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

Не лучше ли ответить на вопросы, а потом приводить следующий, если будет желание. Или в крайнем случае приводить пример с постановкой задачи, а это совсем не не то же самое что комментарии в коде.

А вот вам, таварисч с127, и атветы на вапросы!
1) Вам бы самому парабоать ни мишало.
2) МУМПС тоже работаит.
Универсальный атвет. Ты иму вопрос о индексах, а он - "у нас МУМПС работаит!". Ты иму ишо вапрос про пример, а он - "РАБОТАИТ У НАС МУМПС". Ты ему ишо вапрос пра КС, а он - "ДА пошел ты сам ..... работать!". Обстоятельный и детальный атвет, ничего ни скажешь:) ИМХО сливают рибяты ...
15 мар 06, 10:21    [2449376]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

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

Как раз универсальность дает больше возможности для изменения, в том числе для развития и усовершенствования. С узкоориентированными языками даже самого высокого уровня Вы далеко не уедете.

... многие уже далеко уехали, но не с узкоориентированными, а специализированными языками БД. И уж точно с SQL. А вот насчет Зигзага прогноз верен. Он и как язык БД плох, ну и как дополнение к Джаве вроде совсем не нужен. Она и без него обойдется.
Пустые слова. И зачем только я вам отвечаю...
>Правда многие уже далеко уехали, но не с узкоориентированными, а специализированными языками БД. И уж точно с SQL.
Потребность в специалистах по Java сейчас выше. Сделайте запрос на каком-нибудь JOB-сайте. Она выше даже чем для специалистов по С. SQL болтается опять только как дополнение.
>А вот насчет Зигзага прогноз верен. Он и как язык БД плох
На счет Zigzag можно сказать тоже самое, что про сам SQL. Выяснилось, что Zigzag - язык более высокого уровня, чем SQL. Слабость Zigzag только в отсутствии структурных операторов и дополнительных функций. В конечном счете лучше иметь инструмент (например M) для создания "своей" нужной функции, чем пользоваться "выразительным" языком, на котором сложно представить даже простейшую иерархическую зависимомсть, как в M или Zigzag, например:
животное:млекопитающее:домашнее:собака

Спор между мампсистами и скулистами сводится в конечном счете к тому, что важнее, выразительность или универсальность (мощность). У скулистов главный "конек", это выразительность. А что скулисты ответят на следующее: Zigzag выразительнее SQL, а Java мощнее PL. Получается
Java + Zigzag > PL + SQL. Вы, vadiminfo, ведь не зря сейчас изучаете Java. Да и Zigzag Вам явно не дает покоя. Вы первые о нем всегда вспоминаете. И пожалуйста, не надо больше пустых и общих фраз типа "им больше пользуются". Часто больше пользуются только потому, что меньше знают. На то он и форум, чтобы больше знать ...
15 мар 06, 12:00    [2450102]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
автор
животное:млекопитающее:домашнее:собака

Отнюдь.
Прекрасно нормализуется, главное понять, чего достичь надо.
Да и нет такой отдельной позиции - программист SQL.
Я не встречал что-то.
А вот разработчик под конкретную базу данных - сколько угодно.
И как раз архитектор баз данных, который нормализует данные.
Так что ваши утверждения неверны.
SQL это всего лишь язык работы с данными, который используется как правило в совокупности с алгоритмическими языками. А для работы с данными SQL не так уж и плох, как вам хотелось бы.
15 мар 06, 12:14    [2450200]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Смею предложить себя для желающих понять М. Я работаю с М более десяти лет, заавтоматизировал банк, бухгалтерию и склад практически самостоятельно. Это не реклама мне. Это к тому, что я в М многое умею, но далеко не всё и продолжаю открывать для себя новое.

Итак, приглашаю только заинтересованных и только на моём форуме потому как взаимные обиды ни к чему не приводят.

Итак, ищите меня мылом, ICQ, на трубе - кто реально хочет понять М.
15 мар 06, 12:40    [2450414]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
ggv
автор
животное:млекопитающее:домашнее:собака

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

На Zigzag я могу легко выразить даже "наследование атрибутов". Например, введу такое утверждение:
животное(глаза:есть):млекопитающее(питание:молоко):домашнее(место обитания:дом):собака(звук:лаяние)
Переводится как "Животное имеет глаза и является классом для млекопитающих, которые питаются молоком и которые могут быть домашними, имеющими место обитания дом. Примером класса домашних может быть собака, которая характеризуется звуком лаяния." Теперь на Zigzag я могу сделать запрос
= (глаза:есть,звук:лаяние)
Переводится как "Найти все, что имеет глаза и характеризуется звуком лаяния". Надеюсь мне не надо объяснять, что будет результатом и как реализуется механизм наследования атрибутов. Конечно, если посидеть покряхтеть все эти зависимости можно представить и на SQL ... таблицами. Но это уже будут Ваши проблемы... Добавлю (на всякий случай) возможность работы с таблицами у Zigzag имеется https://www.sql.ru/forum/actualthread.aspx?tid=249335
15 мар 06, 13:17    [2450632]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
Еще проф. Кодд доказал, что все может быть представленно в реляционном виде.
У меня нет желания положить жизнь на доказывание обратного.
Еще раз, может вы не читали -
есть коммерчески успешние реализации иерархических систем, в том числе и с наследованием аттрибутов, построенные целиком и полностью на реляционных базах данных.
Я работаю с одной из таких систем - Tivoli Directory Server. По другому - LDAP server.
Надеюсь, вы не будете отрицать, что LDAP это иерархическая вещь, и что у него есть наследование. Если собираетесь отрицать - начните с RFC.
По-моему, у oracle тоже есть реализация LDAP на Oracle RDBMS.
15 мар 06, 13:46    [2450804]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
ggv
Еще проф. Кодд доказал, что все может быть представленно в реляционном виде.
У меня нет желания положить жизнь на доказывание обратного.
Еще раз, может вы не читали -
есть коммерчески успешние реализации иерархических систем, в том числе и с наследованием аттрибутов, построенные целиком и полностью на реляционных базах данных.
Я работаю с одной из таких систем - Tivoli Directory Server. По другому - LDAP server.
Надеюсь, вы не будете отрицать, что LDAP это иерархическая вещь, и что у него есть наследование. Если собираетесь отрицать - начните с RFC.
По-моему, у oracle тоже есть реализация LDAP на Oracle RDBMS.


вот именно
и чего спорить ?
развитие темы - моделирование на MUMPS
реляционных систем :
http://www.osp.ru/os/2006/01/
15 мар 06, 14:11    [2450968]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
дак что читать то в номере?
http://www.osp.ru/os/2006/01/036.htm - это?
Кстати, интересно.
15 мар 06, 14:34    [2451140]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
интересно, в смысле, вот это - Достоинства и недостатки систем баз данных
- в самом низу страницы.
15 мар 06, 14:39    [2451176]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
ggv
дак что читать то в номере?
http://www.osp.ru/os/2006/01/036.htm - это?
Кстати, интересно.

-Семантический инструмент построения баз данных-

особенно в конце статьи
15 мар 06, 16:03    [2451839]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
К сожалению, мод, это совсем беспредметный разговор. Например:

^индексы сущности(ид.свойства,значение свойства,ид.сущности)=""

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

Давайте Вы, все-таки, прислушайтесь к Sergo Gromov, что ли. Ну здесь же "Сравнение", а не "Изучение".

Это уж через край, ggv, особенно для архитектора баз данных. Наверное Вы хотели сказать не "все может быть представлено", в все может быть уложено в РБД ? А представлено-то как раз в естественном виде. Этого и хотят добиться разработчики ОРСУБД или ИРСУБД (или просто неких инструментов). Однако интереснее обходиться без накладных расходов на маппинг.
15 мар 06, 18:38    [2452734]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
ораклоидальный мампсист - неохота ввязыватся в непродуктивные дискуссии о терминологии.
15 мар 06, 18:53    [2452803]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Спор между мампсистами и скулистами сводится в конечном счете к тому, что важнее, выразительность или универсальность (мощность). У скулистов главный "конек", это выразительность. А что скулисты ответят на следующее: Zigzag выразительнее SQL, а Java мощнее PL. Получается
Java + Zigzag > PL + SQL. Вы, vadiminfo, ведь не зря сейчас изучаете Java. Да и Zigzag Вам явно не дает покоя. Вы первые о нем всегда вспоминаете. И пожалуйста, не надо больше пустых и общих фраз типа "им больше пользуются". Часто больше пользуются только потому, что меньше знают. На то он и форум, чтобы больше знать ...
Приходится исправлять самого себя: Часто больше пользуются только потому, что больше знают. В любом случае им ответить нечем, я умываю руки.
15 мар 06, 19:08    [2452868]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Пустые слова. И зачем только я вам отвечаю...


Мне лично моно и не отвечать. Здесь форум и любой может комментировать сообщения.

okdoky

Потребность в специалистах по Java сейчас выше. Сделайте запрос на каком-нибудь JOB-сайте. Она выше даже чем для специалистов по С. SQL болтается опять только как дополнение.

Это Вы с точки зрения логики кадровика? Для него мож шо и болтается. Но есть технологии ИС и РБД занимает пока ведущее место. Ниче другого более успешного пока себя убедительно не проявило, иначе об этом было бы известно и без нас с Вами. А Вы нашли? Зигзаг? Не смешите тока меня.

okdoky

На счет Zigzag можно сказать тоже самое, что про сам SQL.

Они рядом не стояли. Вы не себе не представляете масштабов того, с чем сравниваете Зигзаг. То как Вы сравниваете языки годится тока для рекламщиков далеких от ИТ.

okdoky

Выяснилось, что Zigzag - язык более высокого уровня, чем SQL.

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

okdoky

Слабость Zigzag только в отсутствии структурных операторов и дополнительных функций. В конечном счете лучше иметь инструмент (например M) для создания "своей" нужной функции, чем пользоваться "выразительным" языком, на котором сложно представить даже простейшую иерархическую зависимомсть, как в M или Zigzag, например:
животное:млекопитающее:домашнее:собака

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

okdoky

Спор между мампсистами и скулистами сводится в конечном счете к тому, что важнее, выразительность или универсальность (мощность).

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

okdoky

У скулистов главный "конек", это выразительность.

Вы не в курсах в чем "коньки" у скулистов. Есть притча про слепых мудрецов. Их подвели к слону. Один потрогал ногу и решил, что слон - это круглый столб. Так и Вы, судя по Вашим постам видете тока ногу от SQL.

okdoky

А что скулисты ответят на следующее: Zigzag выразительнее SQL, а Java мощнее PL.

Что не известно, что Вы понимаете под выразителностью. Она, скорее всего, может иметь смысл в данном контексте, если тока Zigzag язык реляционных БД. Но пока это не известно, тем более Вы его теперь как иерархический позиционируете.
Но пока Zigzag воспринимается рядом с SQL, как кукрузник рядом с современным авиалайнером.

okdoky


Получается
Java + Zigzag > PL + SQL.

Вы бы этого очень хотели. Но Джаве Зигзаг сто лет не нужен, а то что Скуль хорошее дополнение к Джаве даже Вы сказали.
Т.е. пока Zigzag = 0 в этом выражении.

okdoky

Вы, vadiminfo, ведь не зря сейчас изучаете Java.

Джаву изучаю из-за того, что у Оракла на ней много решений для клинтских и серверов приложеий (да и наряду с PL он может использоваться в БД для ХП).
В частности, для OLAP и Dataminig.


okdoky

Да и Zigzag Вам явно не дает покоя. Вы первые о нем всегда вспоминаете.

Название у него запоминующееся. Но как язык БД или универсальный он меня забеспокоит, тока када добьется таких успехов, шобы упоминаться в толстых книгах, а стало быть во многих статьях авторитетов от БД.

okdoky


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

Вы уверены что все Ваши фразы наполнены чем-то стоящим? По-моему, мы на равных в этом плане.
15 мар 06, 20:24    [2453088]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
А мне, ggv, неохота не только ввязываться в дискуссии, но и терпеть непродуктивные накладные расходы. И вот стараюсь убедить начальство перевести нашу ERP систему с Oracle на человеческую платфому. Причем технических возражений уже нет. Остались политические и коммерческие личные интересы.
15 мар 06, 21:07    [2453179]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ораклоидальный мампсист

И вот стараюсь убедить начальство перевести нашу ERP систему с Oracle на человеческую платфому. Причем технических возражений уже нет.

Если у ораклоидального мампсиста и его начальства есть конкуренты, то можно себе представить как многие им теперь завидуют. Даже с Ораклом у этой ERP проблемы, а уж способ лечения много хуже болезни. Жаль шо мало таких добрых людей.
15 мар 06, 21:26    [2453216]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
а я бы сказал по-другому - стремление увести ERP с RDBMS это чистое политическое/личностное решения, и никак не вызвано тпехнологическими причинами.
Интересно, если взять коммерческие ERP, более/меннее распространенные на рынке, сколько из них реализованы не на RDBMS ?
Ну еще можно в процентном отношении от общего кол-ва, в $$$, в кол-вах инсталляций...
15 мар 06, 21:48    [2453252]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить