Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Со сложными полями типа SET или ROW Вы не работали?

Сложные типы - объектные, XML поддерживаются в современных РСУБД. В Оракле, напрмер, кроме того есть коллекции - вложенные таблы, да и просто массивы. Но это все расширения РМД или просто заимствания из других МД. Базовая же МД предполагает атомраные значения данных в полях - т.е. относительно простые типы.
Со сложными типами - сложнее и данные нужные с помощью SQL получать. Потому для их использования нужны особые причины, т.е. када без них тяжело обойтись. Например, если ГИС, то там вычисления всяких площадей и проч.
Что такое тип SET не в курсе. Ну у объектного типа члены могут быть в свою очередь объетными.

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

С нами то РМД-шниками в этом плане все ясно. А вот куда вас классифицировать - непонятка пока полная.
3 мар 06, 20:00    [2415570]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
MIR: Здрасте!? Ну ребята, эскулята! Мы не перестаем удивлять и поражать друг друга. Даже в почти одинаковые слова и предложения вносится разный смысл. Впрочем, слегка есть отличия… То есть, как идентификаторы они уже разные? Поэтому и означают они совсем разное? Правильно? . Читаем еще раз и думаем ...
mir
okdoky
Если у меня есть два сыра, чтобы их идентифицировать мне достаточно сказать, что один сыр находится в левом кармане, а другой в правом.
Однако попробуйте эту информацию преобразовать в данные, то есть любым образом закодировать. И тут же вы обнаружите, что так или иначе изобретете при этом идентификаторы вроде строк "кусок в левом кармане" и "кусок в правом кармане".
Мы говорим об одном и том же, неужели Вы не понимаете? И к чему такое излияние <mir> В который раз вы выказываете потрясающе слабое владение предметом … Да пораскиньте же мозгами, прежде чем что-либо подобное утверждать, глядишь, думать и понравиться :) … Подумайте, подумайте над этим, думать полезно.</mir> Давайте действительно подумаем, но только вместе. Если Вы хотите идентифицировать меня назовите например мыслящий зигзагогулинами. Это все равно лучше, чем быть мыслящим плоскостями или таблицами
3 мар 06, 22:26    [2415989]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
токарь
SergSuper, vadiminfo и др:Можно ли представлять нижний уровень каждой вершины отдельной таблицей?
Эк, куда Вас понесло. Им бы с плоскими таблицами разобраться, а Вы предлагаете вложенные. Представляете сколько реально может быть таблиц? А сколько идентификаторов? Все эти идентификаторы из разных таблиц они связывают другими таблицами. А представляете как им потом приходится разбираться из какой таблицы какой идентификатор и что же он все таки обозначает?

Если хотите, вот пример простой структуры данных на языке Zigzag:
автомобиль:(расположение:площадь:(вокзал:(направление:"Курское")))
Можно перевести как автомобиль расположенный на площади имеющей отношение к вокзалу, который характеризуется направлением "Курское". Это не запрос, а утверждение. Если соответствующего автомобиля, площади и вокзала нет в БД, система создаст соответствующие объекты. Она сама присвоит им простые числовые идентификаторы. Без них действительно не обойтись. Важно, что Вам не нужно думать о них и прежде всего о том как их связать, если они расположены в разных таблицах. Реально будут созданы следующие объекты:
автомобиль:1(расположение:площадь:1(вокзал:1(направление:"Курское")))
3 мар 06, 23:10    [2416111]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 mir соглашайтесь с

okdoky

Если Вы хотите идентифицировать меня назовите например мыслящий зигзагогулинами.

Скорей всего это разновидность какой-то незадачливости, но okdoky сам этого захотел. Да и есть что-то правдивое в этом судя по постам.


okdoky

А представляете как им потом приходится разбираться из какой таблицы какой идентификатор и что же он все таки обозначает?

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

okdoky

Им бы с плоскими таблицами разобраться,

okdoky думает, что если для него это непосильная задача, то и для других тоже. Заниженной самооценкой он не страдает.

okdoky

Если хотите, вот пример простой структуры данных на языке Zigzag:
 
автомобиль:(расположение:площадь:(вокзал:(направление:"Курское")))

Фраза "если хотите" особенно уместна, када в теме топика про Зигзаг ни слова. Т.е. как бы не хотели, а теперь спят и видят. Там где было про зигзаг ниче стоящего не было. Мож здесь када-нибудь что-то появится?

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

Современные РСУБД типа Оракла поддерживаю многомерные модели MOLAP, включают интеллектуальные средста основанные на данных Dataminig, поэтому удивить их чем-то не просто (это для тех кто думает, что плоские таблицы - легкая добыча, например для зигзага). Другое дело, если мы говорим только про базовую модель - РМД, она представляется с помощью таблиц с атомарными значениями данных. И сила в манипулировании данными - достаточно легкое извлечение сложной инфы из БД. А БД и создается именно для получения инфы. Собственно это одна из причин того, что у нас до сих пор реляционная эра. Кстати, еще одна в простой структуре. Ее легче проектировать. Треться в матообосновании.
И, скорей всего, из ныне известных средств в компьютерных технологиях ничего пока нет, чтобы это преодолеть. Это просто показывает практика. Нужно что-то принципиально новое. А перетасованные старые идеи и мелкие заимствания из разных областей как в зигзаге, имеют слишком илюзорные шансы. Если бы в нем было что-то принципиально новое, об этом бы все уже давно знали. Это просто было бы написано во всех толстых книгах.
4 мар 06, 01:12    [2416442]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000

c127

Да, но к сожалению весь СУБД мир (а это почти на 100% РСУБД мир) понимает индекс не так как Вы.

старался никогда не говорить за всех ...

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

Rus000

у Вас есть под рукой определение термина <i>индекс</i>? Может начнем с этого?

Индекс понятие прикладное, строгого определения по-видимому нет вообще. Вы ведь тоже не привели определение Вашего индекса, а объяснили на пальцах.

Что такое индекс в РСУБД можно почитать например тут: C.J.Date "An Introduction to Database Systems", sixth edition, p.724..., там совершенно ясно, что это не просто еще одна таблица. Например рассказывается, что в индексе в хранятся ссылки на страницы, а эта информация из СКЛ-я вообще недоступна, доступность этой информации противоречила бы принципу СУБД (или РСУБД, не помню, но это не важно) о том, что доступ к информации не должен зависить от способа хранения. Так что индекс по Дейту это абсолютно точно не то, о чем Вы говорили. А Дейт это голова.

Но поддержка целостности в Ваших индексах это только одна проблема, есть другие.
Например вот еще одна проблема: если структура
^БИЛЕТЫ(дата,рейс,место)=пассажир
занимает один терабайт, то сколько займет ^БИЛЕТЫИНДЕКСЫ(1,рейс,место,дата) и
^БИЛЕТЫИНДЕКСЫ(2,рейс,дата,место),
которые заменяют индексы и существуют исключительно для упрощения и ускорения поиска?

Индекс в РСУБД тоже занимает место, но все-таки данные тупо не дублирует.

Rus000

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


Нет, такого интереса не было. В постановке задачи было сказано: "Я предлагаю ее решить любым способом, удобным для CACHE". Речь шла об удобстве решения, никаких других условий не было, выбор был Ваш.

Я вообще не знаю что у СКЛ-я после парсингов, это не интересно. Но подозреваю что там в результате получаются машинные коды.

Rus000

Я же не утверждал, что m-проргаммеры используют такой или только такой подход. Нет, конечно. Можно было бы решить эту задачу в терминах классов , и тогда у нас бы тоже голова не болела о поддержке логической целостности данных.

Решите. Любым удобным способом, я же именно с этого и начал.

Rus000

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

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

Rus000

Я же эти подходы не противопоставлял - они суть не противоречат друг другу, т.к. стандарт СКЛ может быть реализован на M, обратное не верно.

Зачем Вы во второй раз повторяете эту легенду, ведь только что обсудили и согласились, что СКЛ в данный момент реализован убого:
MX -- ALEX
Gluk (Kazan)
Большое достижение

Про CBO оптимизатор не спрашиваю. IMHO сравнивать SQL-нашлепку над M с полноценными SQL-серверами не вполне корректно.

если честно - согласен.
единственный аргумент - M развиваеся
и возможно применит другие - специфичные для М -
способы оптимизации выполнения запросов.
(если на то будет воля InterSystems)
а пока для супер-скорости надо кодировать ручками.

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=11#2394023


Rus000

с127

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


ну, "не поверю" - это конечно слабый аргумент :)

Полноту реализации СКЛ-я уже обсудили, ссылка чуть высше, хотите обсудить эффективность?

Rus000

предположим даже что эта реализация sql чуть менее эффектива,

Мы же взрослые люди, по-видимому не первый день работам в программировании, предлагаю обойтись без сказок. Реализация СКЛ-я будет СУЩЕСТВЕННО менее эффективна. Я бы еще послушал, если бы Вы сказали, что М работает сравнимо по скорости или быстрее, но сравнивать СКЛ глупо.

Rus000

но зато мы получаем гибридную систему в которой есть и способы представления данных в иерархии, и в реляционных отношениях и в объектной парадигме. Получаем некое МФУ (многофункциональное устройство), по аналогии с принтер/копир/факс, т.е. получаем большую свободу выбор в реализации проектов...чем плохо-то?

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

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

Еще вопрос. А как в дереве в М системе найти элемент, например того же 'Scott Tiger', если неизвестно на каком уровне он находится и неизвестна глубина дерева? Например проверить есть ли он там и если есть то распечатать к нему путь?
4 мар 06, 04:24    [2416524]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127
..................
Еще вопрос. А как в дереве в М системе найти элемент, например того же 'Scott Tiger', если неизвестно на каком уровне он находится и неизвестна глубина дерева? Например проверить есть ли он там и если есть то распечатать к нему путь?

пробежать по всем ветвям
--------------------------------------------------------------
set z="^T"
for set z=$q(@z) quit:z="" if @z["Scott Tiger" write !,z,@z quit
--------------------------------------------------------------
то есть:
перебирать в цикле все ветви дерева "T"
и если встретится что ищем
напечатать ветвь (z) значение (@z) и остановить пробежку (quit)
если не останавливать напечатает все ветви содержащие "Tiger"
по скорости прокрутка миллиона ветвей в CACHE 5.1 занимает
примерно секунду
------------

было показано решение по авиабилетам на M
а как бы можно увидеть решение на SQL ?
чтоб сравнить по удобству и выразительности программирования ?
4 мар 06, 09:16    [2416586]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
okdoky
токарь
SergSuper, vadiminfo и др:Можно ли представлять нижний уровень каждой вершины отдельной таблицей?
Эк, куда Вас понесло. Им бы с плоскими таблицами разобраться, а Вы предлагаете вложенные. Представляете сколько реально может быть таблиц? А сколько идентификаторов? Все эти идентификаторы из разных таблиц они связывают другими таблицами. А представляете как им потом приходится разбираться из какой таблицы какой идентификатор и что же он все таки обозначает?

Если хотите, вот пример простой структуры данных на языке Zigzag:
автомобиль:(расположение:площадь:(вокзал:(направление:"Курское")))
Можно перевести как автомобиль расположенный на площади имеющей отношение к вокзалу, который характеризуется направлением "Курское". Это не запрос, а утверждение. Если соответствующего автомобиля, площади и вокзала нет в БД, система создаст соответствующие объекты. Она сама присвоит им простые числовые идентификаторы. Без них действительно не обойтись. Важно, что Вам не нужно думать о них и прежде всего о том как их связать, если они расположены в разных таблицах. Реально будут созданы следующие объекты:
автомобиль:1(расположение:площадь:1(вокзал:1(направление:"Курское")))

Мы работаем на чистом M (M3-LITE, GT.M, MSM, CACHE(без SQL) )
продаем пакет "MX" - по функциональности примерно соответствует "1c".
Мы бы хотели расширить список платформ.
Поэтому интересует Zigzag - вероятно близкий по идеологии к М
Не могли бы Вы посоветовать с чего лучше начать изучение Zigzag ?
Кто реально на нем работает ?
kosinec@metalurgs.LV
4 мар 06, 09:46    [2416598]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Какие-то странные вещи, на мой взгляд, говорят сторонники и SQL, и MUMPS. Я правда с MUMPS знаком всего лет пять (с Oracle c 1997 - 7.3), но вроде бы очевидно, что никаких "иерархических БД" там нет. Там вообще нет никаких МД, а есть строка и индексированный массив. И масса очень интересных технологических особенностей. В этом и есть сила MUMPS. Реализуйте МД, которая нравится и вперед. Но не иерархическую же - ее только для каких-то частных задач хорошо использовать. К чему спорить о деревьях ? И при хранении в БД, и для обработки извлеченных данных MUMPS очень хорош. Нет в SQL такого изящества s a=x и s ^a=x. Как и многого другого. Я тоже поначалу теоретизировал, а потом просто взял и изучил этот MUMPS. И ничего от этого не потерял, а многое приобрел.
4 мар 06, 11:32    [2416670]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Какие-то странные вещи, на мой взгляд, говорят сторонники и SQL, и MUMPS.

Однако, дальше идет речь только про "станности" того, что говорят сторонники MUMPS. Т.е. про странности того, что говорят сторонники SQL пока особых пояснений нет.

ораклоидальный мампсист

Я правда с MUMPS знаком всего лет пять (с Oracle c 1997 - 7.3), но вроде бы очевидно, что никаких "иерархических БД" там нет.

Но ведь это и не СУБД? Язык программирования. Но заточенный для работы с иерархическими? или какими? Ить в то время, када он развивался было господство иерархических.

ораклоидальный мампсист

И масса очень интересных технологических особенностей. В этом и есть сила MUMPS.

Фраза "масса очень интересных технологических особенностей" слишком расплывчата. За этим может скрываться что угодно.

ораклоидальный мампсист

Реализуйте МД, которая нравится и вперед.

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

ораклоидальный мампсист

Но не иерархическую же - ее только для каких-то частных задач хорошо использовать.

Тем более шо там c иерархическими IMS форева. Итак два типа МД отпадают. Еще среди реальных известны сетевые и ООМД ОРМД. Для них тоже есть свои форевы.
Что же остается? Академические МД? Т.е. которые пока не нашли реального применения на практике?

ораклоидальный мампсист

К чему спорить о деревьях ?

Так спора о деревьях еще не было как такового. Задачу кое-кто ставил, но так и недоставил.

ораклоидальный мампсист

И при хранении в БД, и для обработки извлеченных данных MUMPS очень хорош.

Это лирика все-таки от рекламы. И то грубовато. "очень хорош" - может сказать какой-то общепризнанный авторитет. Тада еще это может иметь значение.

ораклоидальный мампсист

Нет в SQL такого изящества s a=x и s ^a=x.

Возможно, в этом достоинство SQL, что там таких "изяществ" нет. Кто знает? Мож есть кое-что поважнее подобных изяществ при сранении языков?
Типа ассоциативный доступ, декларативность.

ораклоидальный мампсист

Как и многого другого. Я тоже поначалу теоретизировал, а потом просто взял и изучил этот MUMPS. И ничего от этого не потерял, а многое приобрел.

Здрасте, приехали. Начнем обосновывать преимущества своими примерами? Тада здесь на форуме Фокспро форева. Мож Вы потряли больше чем приобрели? А то что приобрели ваще мож не стоило приобретать? Кто знает?
Тада если по примерам - берем одну из лидирующих СУБД и не паримся. Там примеров личных и успешных больше. На то они и лидирующие.
4 мар 06, 18:03    [2417067]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
В точности так и я рассуждал, когда мне рассказывали про MUMPS. А потом просто взял и изучил. Не без везения - мне хорошо объяснили суть, сам может и не осилил бы, хотя язык, как часть MUMPS, весьма прост. А vadiminfo не повезло. Я разочарован, что в SQL нет изяществ MUMPSа, а Вы надеетесь, что это достоинство SQL. Интересно, Вы хоть поняли суть того изящества, которому противопоставили рекламные слоганы ? Когда институт закончите (сейчас я думаю где-то на втором курсе ?), уже сложнее будет разбираться в инфотехнологиях.
4 мар 06, 19:50    [2417316]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
MX -- ALEX
Поэтому интересует Zigzag - вероятно близкий по идеологии к М
Не могли бы Вы посоветовать с чего лучше начать изучение Zigzag ?
Кто реально на нем работает ?
Zigzag есть смысл изучать, если Вы используете или планируете использовать Java. Фактически, это язык ОРСУБД Sav Zigzag, которая представляет собой API (или библиотеку Java классов) для интерпретации Zigzag-выражений. ОРСУБД Sav Zigzag стала известной совсем недавно, где-то в 2002, когда появилась наиболее быстрая рабочая версия Java 1.3. Собственно уже имеется несколько Java ОРСУБД http://directory.google.com/Top/Computers/Programming/Languages/Java/Databases_and_Persistence/Database_Management_Systems_-_DBMS/Object-Relational/, но все они опираются на маппирование сложных объектов в табличное SQL-представление. Zigzag, несколько необычный язык, сочетающий в себе реляционную алгебру с алгеброй классов. Что понимается под алгеброй классов? Фактически это операции с иерархически связанными объектами, которые образуют классы. Здесь под классом, как и отношением, понимается множество. Для примера могу ответить на
c127
Еще вопрос. А как в дереве в М системе найти элемент, например того же 'Scott Tiger', если неизвестно на каком уровне он находится и неизвестна глубина дерева? Например проверить есть ли он там и если есть то распечатать к нему путь?
На Zigzag это решение будет выглядеть так
= : Scott Tiger
Я даже не указывал имя класса (верхнюю вершину дерева). Все объекты в отношениях и классах индексируются. Поэтому ответ будет мгновенный, даже если этих объектов в БД миллионы. Никакого перебора не требуется. В отличие от SQL-СУБД, целостность поддерживается автоматически. Почти старый пример:
автомобиль:(расположение:(площадь:(вокзал:(направление:Казанское))))
Реально, здесь пять объектов связаны отношениями:
автомобиль-расположение
расположение-площадь
площадь-вокзал
вокзал-направление
Вокзалу, который здесь фигурирует, мы можем задать конкретное имя:
вокзал:(направление:Казанское)=вокзал:Казанский;
В результате изменения произойдут как в отношении площадь-вокзал, так и в отношении вокзал-направление.

Если Вас интересуют чисто иерархические зависимости, еще один пример:
животное:млекопитающее:домашнее:собака;
Здесь реально мы ввели в БД 4 объекта:
животное
животное:млекопитающее
животное:млекопитающее:домашнее
животное:млекопитающее:домашнее:собака
Удалив объект животное, мы удалим увы все подчиненные объекты, то есть класс животных. Чтобы ввести новый объект для которого все перечисленные выше объекты, обозначают класс можно использовать такие утверждения:
:собака:моя;
:собака:(соседская)
По аналогии с деревом мы к вершине собака добавляем новые вершины.
Примеры использования или внедрения, в которых я участвовал здесь http://savtechno.com/indexru.html. Там же есть ссылка на документацию (справочную) по самому языку http://savtechno.com/docs/z/ZLanguage.html
4 мар 06, 20:33    [2417813]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ораклоидальный мампсист
В точности так и я рассуждал, когда мне рассказывали про MUMPS.

Значит было время, когда Ваши рассуждения были более рациональны, чем теперь. А счас Вам остается только лирические какие-то доводы приводить.

ораклоидальный мампсист

А потом просто взял и изучил. Не без везения - мне хорошо объяснили суть, сам может и не осилил бы, хотя язык, как часть MUMPS, весьма прост. А vadiminfo не повезло.

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

ораклоидальный мампсист

Я разочарован, что в SQL нет изяществ MUMPSа, а Вы надеетесь, что это достоинство SQL.

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

ораклоидальный мампсист

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

Какой институт? Изящных искусств? Я туда вообще не собираюсь. А по инфотехнологиям увы читают больше про SQL, реляционные БД. Про МД и что их поддерживают СУБД, а не просто проги к файлам пишут и называют это МД. Мож про МУМПС и читали давно когда-то в институтах. Но когда это было? Инфотехнологии с тех пор ушли далеко вперед. Так что неувязочка у Вас и тут.
4 мар 06, 21:24    [2417865]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

В отличие от SQL-СУБД, целостность поддерживается автоматически.

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

okdoky

Zigzag есть смысл изучать, если Вы используете или планируете использовать Java.

Самая идея Бд - данные предназначенные для разных прог на разных языках имеет проблемы тада для Зигзага. Вот теперь и думайте про смысл его изучать - тратить время.

MX -- ALEX

Мы бы хотели расширить список платформ.
Поэтому интересует Zigzag - вероятно близкий по идеологии к М

Так значит М нуждается еще в каких-то языках? Тем более малоизвестных? Вот SQL никакой Зигзаг сто лет не нужен.
4 мар 06, 21:33    [2417879]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
ораклоидальный мампсист
А vadiminfo не повезло. Когда институт закончите (сейчас я думаю где-то на втором курсе ?), уже сложнее будет разбираться в инфотехнологиях.
Да старый он уже. Какой институт? Какие инфотехнологии? Тут вся надежда на скорлупу. Глядишь до пенсии и дотянет. Лишь бы молодые разные выскочки ее не раздолбили раньше времени.
4 мар 06, 22:21    [2417944]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Да старый он уже. Какой институт? Какие инфотехнологии? Тут вся надежда на скорлупу. Глядишь до пенсии и дотянет. Лишь бы молодые разные выскочки ее не раздолбили раньше времени.

Молодые выскочки, не умеющие вятно ставить задачи, отличать деревья от других графов, не знающие собсно скорлупы, врядли раздолбают эту сколупу. Ее не раздолбали пока кое-кто попродвинутей. А если что и появляется стоящее (а не Зигзаг и иже с ним), то оно на раз оказывается в Оракле и других РСУБД лидирующих производителей.
Када okdoky ставил по началу задачи сам же и признал шо у Зигзага то того нет то другого, что для SQL семечки. И тада к Джаве. Но Джава и в Оракле сидит. В Скуле Net. Кого эти выскочки удивят в инфотехнологиях Зигзагами? С такими до пенсии дотянут в скорлупе и те кто еще не родился.
Смешно и грустно.
4 мар 06, 22:51    [2417981]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ораклоидальный мампсист
В точности так и я рассуждал, когда мне рассказывали про MUMPS. А потом просто взял и изучил. Не без везения - мне хорошо объяснили суть, сам может и не осилил бы, хотя язык, как часть MUMPS, весьма прост. А vadiminfo не повезло. Я разочарован, что в SQL нет изяществ MUMPSа, а Вы надеетесь, что это достоинство SQL. Интересно, Вы хоть поняли суть того изящества, которому противопоставили рекламные слоганы ? Когда институт закончите (сейчас я думаю где-то на втором курсе ?), уже сложнее будет разбираться в инфотехнологиях.

По стилю - ЧАЛ. Во всяком случае очень похоже. Так что могу уже представить дальнейший диалог

okdoky
автомобиль:(расположение:(площадь:(вокзал:(направление:Казанское))))

А что измениться если я запишу так?
<автомобиль>
  <расположение>
     <площадь>
        <вокзал>
          <направление>
             Казанское
          </направление>
        </вокзал>
     </площадь>
  </расположение>
</автомобиль>

Что в зигзаге есть принципиально новое, чего нет в XML?(Надеюсь с тем что XML бесперспективна как БД разногласий нет?)
5 мар 06, 01:32    [2418189]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
SergSuper: То, что Вы показали на XML, это дерево, а не не отношение.
okdoky
В отличие от SQL-СУБД, целостность поддерживается автоматически.
Здесь вместо SQL-СУБД можно поставить XML.
5 мар 06, 09:34    [2418285]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo
okdoky

В отличие от SQL-СУБД, целостность поддерживается автоматически.

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

okdoky

Zigzag есть смысл изучать, если Вы используете или планируете использовать Java.

Самая идея Бд - данные предназначенные для разных прог на разных языках имеет проблемы тада для Зигзага. Вот теперь и думайте про смысл его изучать - тратить время.

MX -- ALEX

Мы бы хотели расширить список платформ.
Поэтому интересует Zigzag - вероятно близкий по идеологии к М

Так значит М нуждается еще в каких-то языках? Тем более малоизвестных? Вот SQL никакой Зигзаг сто лет не нужен.

to okdoky -
Вам спасибо за информацию по ZIGZAG !
to vadiminfo -
К сожалению, Вы не так поняли .
M ни в чем не нуждается .
Система MX - функционально аналог 1с - реализована на чистом M (MUMPS)
на четырех платформах (серверах ) M3, GTM, MSM, CACHE
и без использования SQL - хотя если бы надо было - то обязательно
применили бы SQL.
MX можно в принципе реализовать на любом M-подобном языке
В частности - предположительно - на ZIGZAG
Почему бы не поэкспериментировать ?
Почему все поголовно должны терзать только SQL ?
Шаг влево - шаг вправо - расстрел ?

Естественный отбор - двигатель развития.
Принуждение - например браки между царственными особами
или навязанная гулагом или рекламой политическая или программная
идеология - причина деградации.
5 мар 06, 10:11    [2418311]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Если Вас интересуют чисто иерархические зависимости, еще один пример:
животное:млекопитающее:домашнее:собака;
...
Чтобы ввести новый объект для которого все перечисленные выше объекты, обозначают класс можно использовать такие утверждения:
:собака:моя;
:собака:(соседская)
По аналогии с деревом мы к вершине собака добавляем новые вершины.
Для данного примера правильнее конечно сказать не к вершине, а к вершинам "собака". Это как с хитрым примером на счет "с", который скулисты не могли понять. Имя "собака" может повторяться в разных классах: животное, рисунок, ругательство и т.д. Для более точной идентификации мне придется использовать более полное имя. Например:
= животное:собака
Знак двоеточие означает "подчиненность" или "принадлежность". Уровней иерархии в классе (в дереве) между именем "животное" и "собака" может быть несколько, как в нашем примере.
5 мар 06, 13:07    [2418458]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
SergSuper: То, что Вы показали на XML, это дерево, а не не отношение.
okdoky
В отличие от SQL-СУБД, целостность поддерживается автоматически.
Здесь вместо SQL-СУБД можно поставить XML.


okdoky:То, что Вы показали на зигзаге, это дерево, а не не отношение.
Я к тому что давайте обосновывать как-то свои заявления. Вопрос был конкретный, ответ - весьма абстрактный.
И кстати что вы имеете ввиду под целостностью?

MX -- ALEX
Почему все поголовно должны терзать только SQL ?

Дык народ ленивый нонче пошел. Индексов вручную, даже на таком приятном языке, не хотят поддерживать, хотят чтоб СУБД за них это делала.
5 мар 06, 14:40    [2418563]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

К сожалению, Вы не так поняли .
M ни в чем не нуждается .
Система MX - функционально аналог 1с - реализована на чистом M (MUMPS)
на четырех платформах (серверах ) M3, GTM, MSM, CACHE
и без использования SQL - хотя если бы надо было - то обязательно
применили бы SQL.
MX можно в принципе реализовать на любом M-подобном языке
В частности - предположительно - на ZIGZAG
Почему бы не поэкспериментировать ?
Почему все поголовно должны терзать только SQL ?
Шаг влево - шаг вправо - расстрел ?

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


Наверное, не так я понял. Потому шо тоже думаю что М врядли нуждается в Зигзаге. Но SQL туда вроде внедрен - видел в литературе М среди таких языков, в которые SQL внедрен. Кстати, вот вам и наводка про SQL.

Про МХ я не ообратил действительно внимание. но теперь не понял про платформы совсем. КЕШ - это СУБД. Стал быть Вы платформами СУБД называете? Обычно платформами называю аппаратное обеспечение и (или) ОС.
Если КЕШ платформа, то что МХ? Совокупность клиентов к СУБД? Или шо?
И шо такое M3, GTM, MSM? Тоже СУБД? Впервые тада слышу такие.
Т.е. вопрос - шо Вы называете платформой? И в свете этого хде там М и кто такие эти перечисленные платформы и как они соотносятся с МХ?

Зигзаг М подобный? Но, конечно, Вам виднее использовать Зигзаг или нет.

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

Не расстрел, но риски слишком велики.

Да естественный отбор. Пусть это вульгарный Дарвинзм, но вот этот отбор и отобрал SQL. Я Вам про это и говорю.

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

Но мне интересно любая информация и про М и про Кеш. Но, конечно, не изучать, а так - представлять себе. Для эрудиции.
5 мар 06, 17:37    [2418693]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
[quot c127]
было показано решение по авиабилетам на M
а как бы можно увидеть решение на SQL ?
чтоб сравнить по удобству и выразительности программирования ?

Никаких проблем, смотрите, оно уже больше года там. Читаем пост с постановкой задачи:

Раз пошла такая пъянка то вот задача, предложенная сторонниками Версанта
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=138641&pg=2#1206843
.....
Приблизительное СКЛ решение там обсуждается, можно ознакомиться.

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=10#2388599



На два допольнительных вопроса ответ тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406559
от слов "Вот решения на СКЛ-е для сайбейз АСА" и вниз.
6 мар 06, 10:20    [2420046]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
MX -- ALEX

Почему все поголовно должны терзать только SQL ?
Шаг влево - шаг вправо - расстрел ?

Да вот по этому:
Есть картотека персонала 100 полей уникальный № поиск возможен по некоторым полям.
Решение для РБД тривиально: таблица на 100 полей уник. индекс по № индексы по полям поиска. Все.
Решение для М я знаю :) но хочется сначала послушать М-технологов.
Ждемс.
6 мар 06, 10:28    [2420086]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo

Если КЕШ платформа, то что МХ? Совокупность клиентов к СУБД? Или шо?
И шо такое M3, GTM, MSM? Тоже СУБД?
А чтобы вытеснить теперь нужно не тока догнать, но и иметь ощутимые преимущества. Иначе зачем переходить?
Вот Вы сравниваете себя с 1с. А за ним Скуль маячит. Реально Вы или Ваши платформы должны соревноваться со Скулем. А это могут себе сегодня реально позволить тока Оракл, DB2 ну мож Сибэйс. Все. Вот теперь соревнуйтесь с 1с.
Но мне интересно любая информация и про М и про Кеш. Но, конечно, не изучать, а так - представлять себе. Для эрудиции.

--M3-LITE
--GT.M
--MSM
--CACHE
это все СУБД-родственники - общий язык у всех - MUMPS
и очень схожая архитектура баз данных,
для простоты мы их всех обзываем "M".
Самая продвинутая и быстрая из них - CACHE (5.1).

MX - приложение - написано на чистом MUMPS - без наворотов,
поэтому работает на любой из этих четырех СУБД.
MX реально конкурирует с "1с-LATVIA" ,
хотя "1с"-очень хорошо адаптрована под наши местные законы -
этим занимаются сразу несколько латвийских фирм

согласен - только рынок расставит точки.
6 мар 06, 10:35    [2420112]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Забыл сказать

MX -- ALEX

то есть:
перебирать в цикле все ветви дерева "T"
и если встретится что ищем
напечатать ветвь (z) значение (@z) и остановить пробежку (quit)
если не останавливать напечатает все ветви содержащие "Tiger"
по скорости прокрутка миллиона ветвей в CACHE 5.1 занимает
примерно секунду

Пробег по миллиону записей в оракле 8 на пентиуме 500МГц м IDE диском и 128 МБ ОЗУ (может 256, не помню, все равно он ее всю не занимал) в 2000 году тоже занимал примерно секунду. Никаких индексов, никакой оптимизации, тупо поставили оракл, заполнили таблицу и протестировали. Перебор миллиона записей при стандартном моделировании древовидной структуры это полный аналог прохода по дереву с миллионом вершин.

А после индексации, тоже без настроек, все по умолчанию, в секунду стало выполняться примерно 200 запросов по нахождению записи в таблице с 1млн. записей.
6 мар 06, 10:40    [2420137]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить