Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
Хе-хе...
Guest
mir
Развенчайте миф.

В огороде бузина, в Киеве дядька.
Миф не в том, что системы sql научились использовать те же btree индексы, а в том, что форма написания "индексы там такие же, как в РСУБД" может у непосвященного вызвать ассоциативно неверное представление что сначала индексы появились в sql а потом в mumps. Дело в том, что мампсы работали во всю когда sql и в планах не числился.
Что касается вопроса какие индексы используют имеющиеся имплементации sql - то тут во-первых нужно смотреть о какой именно имплементации идет речь, во-вторых а в чем смысл, если в sql нельзя использовать индексы иначе как объявить их наличие и упрашивать оптимизатор обратить на них внимание? Ну есть, и что? Программистам на sql остается только догадываться как именно движок начнет (или не начнет) их использовать, поумничать на форумах что есть разные виды, что у них есть свойства, и в какой имплементации каких индексов нет.
22 фев 06, 15:16    [2382643]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Нда, скока народ всего знает и не знает.

В моем представлении Оракл - это :
1. SQL Запрос
2. Парсинг запроса в действия
3. Выполнение элементарных действий на которые разбит запрос с учетом индексов, cost/rule оптимизацией статистика и п.р.
4. Составление набора возвращаемых данных.

(Ораклисты, не пишите что есть еще 50 уровней)

Так вот, Каше и пр. - это только N3 - сам выполняешь элементарные действия поиска по индексу и пр. А так это все делает Оракл.

ВОТ И ВСЕ. Нет никакой магии.
22 фев 06, 15:23    [2382682]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Хе-хе...
Guest
Dimonische
Так вот, Каше и пр. - это только N3 - сам выполняешь элементарные действия поиска по индексу и пр. А так это все делает Оракл.

Как раз именно в каше есть препроцессор sql который выполняет то же самое. Есть и запрос и парсинг и построение плана и выполнение элементарных действий и оптимизация. Если sql - то иначе видимо никак.
Если бы в оракле были операции на индексах, доступные программисту, то чтобы делал программист на оракле? Думаете, никогда не воспользовался? Сомневаюсь. Скорее появились бы исследователи как на этих операциях все заоптимизировать легко и просто. И точно так же писали бы - сам выполняешь что тебе надо. :-)
22 фев 06, 15:44    [2382804]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Хе-хе...
[quot Dimonische]
Если бы в оракле были операции на индексах, доступные программисту, то чтобы делал программист на оракле? Думаете, никогда не воспользовался? Сомневаюсь. Скорее появились бы исследователи как на этих операциях все заоптимизировать легко и просто. И точно так же писали бы - сам выполняешь что тебе надо. :-)


Дорогой Хе-Хе!

Хе-хе (каламбур аднак), но Оракл сейчас рулит по количеству пользователей-программистов. Значит путь Оракла большинству интересней.
22 фев 06, 16:39    [2383148]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Хе-хе...
Что касается вопроса какие индексы используют имеющиеся имплементации sql - то тут во-первых нужно смотреть о какой именно имплементации идет речь, во-вторых а в чем смысл, если в sql нельзя использовать индексы иначе как объявить их наличие и упрашивать оптимизатор обратить на них внимание? Ну есть, и что? Программистам на sql остается только догадываться как именно движок начнет (или не начнет) их использовать, поумничать на форумах что есть разные виды, что у них есть свойства, и в какой имплементации каких индексов нет.

так в этом и преимущество sql :)
22 фев 06, 16:55    [2383223]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Хе-хе...
Guest
Dimonische
Дорогой Хе-Хе!
Хе-хе (каламбур аднак), но Оракл сейчас рулит по количеству пользователей-программистов. Значит путь Оракла большинству интересней.

Надеюсь и дальше буду не дешевкой. Я в курсе, что ораклоиды считают себя самыми многочисленными, mssql-цы себя считают самыми многочисленными, а пользователям excel вообще невдомек что бывают другие базы. А к чему это? Традиционное меряние?
22 фев 06, 17:02    [2383256]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Хе-хе...
Dimonische
Так вот, Каше и пр. - это только N3 - сам выполняешь элементарные действия поиска по индексу и пр. А так это все делает Оракл.

Как раз именно в каше есть препроцессор sql который выполняет то же самое. Есть и запрос и парсинг и построение плана и выполнение элементарных действий и оптимизация. Если sql - то иначе видимо никак.
Если бы в оракле были операции на индексах, доступные программисту, то чтобы делал программист на оракле? Думаете, никогда не воспользовался? Сомневаюсь. Скорее появились бы исследователи как на этих операциях все заоптимизировать легко и просто. И точно так же писали бы - сам выполняешь что тебе надо. :-)
Ув. хе-хе. Вы, видимо, не совсем в курсе истории БД-технологий. Сначала пару десятков лет как раз все программеры писали работу с БД на низком уровне. То есть "операции на индексах, доступные программисту" были как раз очень долгое время. Этакий ассемблер баз данных.

Кстати, хорошая аналогия, на ассемблере тоже очень долго писали программы, как все знают. Но почему-то (подразумевается ирония) магистральное программирование пошло в сторону языков высокого уровня, в которых встроенный в компилятор оптимизатор сам решал, какой физически код сгенерировать. То же произошло и в технологиях БД. Там тоже магистральная линия развития двинулась в сторону повышения уровня абстракции. От "ассемблера" к "ЯВУ", если хотите. Да в общем, по тем же самым причинам.

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

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

В общем, помедитировав над вопросом, почему ЯВУ в мейнстриме категорически вытеснили ассемблер (в свою очень узкую нишу), можно понять, почему РСУБД живут и побеждают, а про MUMPS-подобные системы можно сказать "пациент скорее мертв, чем жив". Многочисленные success-story про внедрение M-систем на заводах и т.п. ничуть при этом не удивляют. Хорошим программистам все под силу. Ведь, возвращаясь к аналогии с ассемблером, на ассемблере тоже можно писать чудесные программы. Или не на ассемблере, так на чистом API, без всяких компонентов, RAD и т.п. Ведь хорошим программистам все под силу, правда?

Но на каждую программу на асме найдется милион программ на ЯВУ. И на каждую success-story про использование M найдется милион success-story про использование РСУБД. По тем же причинам. И не зря, не так ли?
22 фев 06, 17:12    [2383292]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Если бы изначально классические языки программирования обладали более развитыми средствами для работы с хранимыми данными, то еще неизвестно насколько были бы востребованы SQL-сервера, невзирая на стандарт.

Наверняка любой программист пользовался бы больше предоставляемыми возможностями языка, чем возможностями другой технологии.
22 фев 06, 17:46    [2383417]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Хе-хе...
Guest
mir
Ув. хе-хе. Вы, видимо, не совсем в курсе истории БД-технологий.

Я не смог понять откуда такой вывод, даже обидно как-то стало. Неужто мое иронизирование было принято за чистую монету? Или просто принято незнакомому человеку приписать что хочется.
mir
Но на каждую программу на асме найдется милион программ на ЯВУ. И на каждую success-story про использование M найдется милион success-story про использование РСУБД. По тем же причинам. И не зря, не так ли?

Я бы даже добавил и "не даром".
Еще раз повторю - я против того чтобы говорить что "в мампсе как в РСУБД". Правильнее говорить "в РСУБД как в других СУБД". Такие неточности режут слух и я позволю себе уточнить.
Кстати, ни явы и асма никогда не пользовал в полный рост. Для меня это все только на уровне общей эрудиции. Будем считать что Ваш пост другим читателям более понятен.
Кстати, представьте себе, что есть не только чудики которые отвергают яву, но и такие которые даже в этом не нуждаются.
22 фев 06, 17:49    [2383428]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
ЯВУ это Язык Высокого Уровня
22 фев 06, 18:01    [2383465]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
MX -- ALEX
Guest
Надо признать - действительно M сам не оптимизирует процесс отработки
запроса и если статистика или железо поменялись - не учтет
и не адаптируется
Однако 90 % систем в которых это и не так важно
Например все мелкие конторки - фирмочки - магазинчики
А их тысячи тысяч
Ну нет там необходимости давать ответ менее чем за секунду
А больше чем секунду M не думает практически никогда

возьмем EXCEL
15 000 000 пользователей в 2000-ом году
никакой оптимизации-механизации
все примитивно - тупо - в ячейках
база данных ни к черту
однако востребован и очень .

И если сегодня система типа "1с" на "M" более удобна,
работает быстрее, настраивается проще, сопровождается школьниками
и без проблем - то покупают M

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

проблемы
- малораспространен
- нет самооптимизации построения запросов на очень больших базах
- дорогие лицензии и неправильная ориентация главного
разработчика (фирма InterSystems) - игнорируют мелкоту, а на крупных системах M не имеет преимуществ перед ORACLE
=========================================
22 фев 06, 18:05    [2383473]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
SergSuper
Member

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

козыри M
- простота языка

и наглядность!
одно это чего стоит
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
22 фев 06, 18:21    [2383513]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Последний мой пост в этом топике ...
http://tel-bases.narod.ru/ - писано "в лоб" на М-GUI ... самая большая предлагаемая база - Киев, около полутора миллионов записей. В проге описан механизм импорта/экспорта, можно пользовать без ограничений, заодно проверяется визуально время вставки одного элемента в существующую базу с добавлением (а не перестроением) индекса.
22 фев 06, 18:27    [2383538]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Кхе еще раз
Guest
SergSuper
MX -- ALEX

козыри M
- простота языка

и наглядность!
одно это чего стоит
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d

Есть сомнения что это наглядно?
Ну тогда изобразите код программы с аналогичной выборкой и выводом результатов на другом языке.
22 фев 06, 19:06    [2383641]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

SergSuper wrote:
> MX -- ALEX
>
> козыри M
> - простота языка
>
>
> и наглядность!
> одно это чего стоит
> s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
дык, батенька, никто не заставляет ТАК писать... так МОЖНО писать...
если маразма не изменяет это нечто вроде
set d=20060202-.1
for
..set D=$o /*не помню чего значит*/ (A(d))
..quit:'d
..quit:d>20060227.9
..write !,A(d),?20,d

так вроде понятнее стало? (ну, за исключение форматного вывода)ю

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

22 фев 06, 19:37    [2383720]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Кхе еще раз
SergSuper
MX -- ALEX

козыри M
- простота языка

и наглядность!
одно это чего стоит
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d

Есть сомнения что это наглядно?
Ну тогда изобразите код программы с аналогичной выборкой и выводом результатов на другом языке.

Во-первых добавление всяких префиксов к дате (20060227.9) - это уже издержки проектирования, вызванные издержками СУБД
Во-вторых уже приведенное здесь select child from t1 where parent="Иванов " and age=16 - достаточно знать английский, не надо быть программистом чтоб понять что написано
22 фев 06, 19:43    [2383735]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
Dimonische
Member

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

козыри M
- простота языка

и наглядность!
одно это чего стоит
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d


Дорогой SergSuper, вы очень примитивный индивид. Ведь каждому же очевидно что здесь написано! :)
22 фев 06, 21:33    [2384078]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Добавлю свои соображения исходя из 13-летнего опыта работы с M-систмами (MSM,Cache)

1) mir очень убедительно все разложил и во многом прав, и в частности в том, что M - не является ЯВУ, со всеми вытекаюиватщими.

2) Очевидно, что sql запрос в РСУБД все равно парсится преобразуется в исполняемый низкоуровневый код. Поэтому сравнивать sql и M абсолючно бессмысленно - он на разных уровнях абстракции.

3) Проектировать и кодировать на M можно быстро и эффективно, даже не сомневайтесь, однако требуется доп.интерфейсный инструментарий

4) Учитывая специфику древовидной организации данных на ЛОГИЧЕСКОМ уровне, M эффективен в задачах, ориентированных на хранение и обработку информации при ИЗВЕСТНОМ ID объекта - именно тогда используется бинарный поиск на уровне субд для извлечения содержимого объекта, а также на задачах в которых объекты имеют неоднородную природу, ввиду того, что для таких объектов дерево их представляющее будут иметь разную ветвистость.

5) М-системы базируются на хранении данных в некоторой УПОРЯДОЧЕННОЙ последовательности (collation) ключей (именованных ветвей дерева) причем при операциях вставки, субд обязательно вставляет новый объект в нужное место сортирующей последовательности ключей. Отсюда следствие - операции вставки являются медленными, потому как в случае отсутствия места в дисковом блоке субд производит т.н.ращепление блока (split) и перестройкой блоков указателей.

6) Операции выборки думаю сопоставимы по скорости с РСУБД, при наличии соответствующих индексов по атрибутам объектов, участвующих в запросе. При их отсутствии, приходится сканировать контейнерные для атрибутов объекты с целью проверки условий выборки.

7) Операции удаления объектов быстры ввиду того, что для удаления субд требуется просто очистить указатель на родительскую вершину для объекта.

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

И еще. Если долго работать с деревьями, то начинаешь думать и проектировать деревьями, и даже обладая базисом рел.алгебры потом трудно уже себя заставить думать ее (алгебры) концепциями. Тем не менее, принципы нормализации отношений (пусть даже выраженных деревьями) обязательно применяются - куда же без них ;)
22 фев 06, 21:47    [2384116]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
SergSuper

А что такое тогда хеш индекс? Я считал что это когда ключом для индекса выступает не само значение аттрибута, а его хэш функция. Тогда остаются те же уровни в Б-дереве, количество которых и определяет время поиска.
А на самом деле что это тогда?


Это не бинарное-дерево, у дерева скорость поиска от количества данных зависит логарифмичесаки, а у хеш индекс - константа. Дерево можно использовать при запросах вида Z>10, хеш индекс нельзя. Насколько я понимаю хеш индекс это хеш таблица.
http://algolist.manual.ru/ds/s_has.php

Там есть ссылки на Кнута и пр.


Хе-хе..
Более того, индексы там такие же, как в РСУБД, ничего нового человечество пока не придумало

Вот так и рождаются мифы. Осталось добавить для полноты гармонии, что MUMPS написан на SQL. И что до SQL ничего не было, и писали программисты чепуху, и было сотворение мира, и SQL велик, акбар, аминь и все такое. В хумор.

Ну зачем же постить глупости, прочитайте предложение полностью. Предложение заканчивается так: "а если вдруг придумало то можно не сомневаться что оно уже перекочевало в РСУБД."

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

Хе-хе..

Если бы в оракле были операции на индексах, доступные программисту, то чтобы делал программист на оракле?

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

Кхе еще раз
SergSuper
MX -- ALEX

козыри M
- простота языка

и наглядность!
одно это чего стоит
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d

Есть сомнения что это наглядно?
Ну тогда изобразите код программы с аналогичной выборкой и выводом результатов на другом языке.

Так в том же и дело, что понять нельзя, что оно значит. Если Вы объясните, что делает эта безусловно наглядная и интуитивно понятная абракадабра, то я попробую изобразить нечто подобное на СКЛ-е.

Хотя тут уже вроде и без меня изобразили, правда кешевцы с мумпсовцами предпочли не заметить:
mir
Чё-то я не пойму, как строка
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
длиной 65 знаков вдруг считается короче строки
select child from t1 where parent="Иванов " and age=16
длиной 54 знака?

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


AlexKB
Если бы изначально классические языки программирования обладали более развитыми средствами для работы с хранимыми данными, то еще неизвестно насколько были бы востребованы SQL-сервера, невзирая на стандарт.

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


А что такое классичесие языки программирования? ЛИСП?

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

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

Sergo Gromov
Последний мой пост в этом топике ...
http://tel-bases.narod.ru/ - писано "в лоб" на М-GUI ... самая большая предлагаемая база - Киев, около полутора миллионов записей. В проге описан механизм импорта/экспорта, можно пользовать без ограничений, заодно проверяется визуально время вставки одного элемента в существующую базу с добавлением (а не перестроением) индекса.


Это вообще непонятно к чему, а в чем достижение-то? В том что много работали, написали "в лоб", а в результате - пшик? Полтора миллиона записей это небольшая база, тут где-то говорили что у дойчен телеком 50 млн записей в день на ДБ2, перестроение индекса в РСУБД при добавлении элемента тоже происходит далеко не всегда и не всякого, экспорт-импорт поддерживается, визуально время вставки выдать пользователю в случае необходимости ничего не стоит.
23 фев 06, 01:07    [2384455]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Rus000
3) Проектировать и кодировать на M можно быстро и эффективно, даже не сомневайтесь, однако требуется доп.интерфейсный инструментарий

Может быть.
Как-то просил кого-то (не помню кого, но он тоже про эффективность писал) показать на примере. Допустим есть такая структура - начальник- подчинённые, у каждого подчинённого могут быть свои подчиненные, вложенность неопределена. Требуется вывести список всех сотрудников вместе с суммарной зарплатой всех их подчинённых. Собственно я много кому эту задвчу предлагаю. Вроде типично иерархическая задача. На чистом SQL она решается не очень красиво. Хотелось бы посмотреть как она решается на языках учитывающих специфику древовидной организации данных . Никто из сторонников М так решения и не привёл. Если не трудно - было бы интересно посмотреть.

Rus000

5) М-системы базируются на хранении данных в некоторой УПОРЯДОЧЕННОЙ последовательности (collation) ключей (именованных ветвей дерева) причем при операциях вставки, субд обязательно вставляет новый объект в нужное место сортирующей последовательности ключей. Отсюда следствие - операции вставки являются медленными, потому как в случае отсутствия места в дисковом блоке субд производит т.н.ращепление блока (split) и перестройкой блоков указателей.

По-моему типичные проблеммы любого индекса
Rus000

7) Операции удаления объектов быстры ввиду того, что для удаления субд требуется просто очистить указатель на родительскую вершину для объекта.

Если существует расщепление блока, то должна быть и обратная операция, да и балансировка индекса. Либо надо индекс периодически перестраивать. Чего-то Вы тут недоговариваете :)

Опять же ничегео принципиального иного по сравнению с любой другой СУБД от фокса до оракла тут нет
Rus000

И еще. Если долго работать с деревьями, то начинаешь думать и проектировать деревьями, и даже обладая базисом рел.алгебры потом трудно уже себя заставить думать ее (алгебры) концепциями.

Вот объясните в чем разница. Допустим таже структура: Цех/Работник/Дети. Можно сделать это деревом и обращаться к этому условно $A('Литейный цех','Иванов','Вася').
А можно тоже самое представить таблицей с соответствующими полями и обращаться как select * from tbl where Цех='Литейный цех' and Работник='Иванов' and Дети='Вася'. Получается разница только в синтаксисе. Мне чего-то не уловить концепцию проектирования деревьями
23 фев 06, 01:50    [2384504]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
[quot c127
mir
Чё-то я не пойму, как строка
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
длиной 65 знаков вдруг считается короче строки
select child from t1 where parent="Иванов " and age=16
длиной 54 знака?

[/quot]
Уважаемые с127 и mir ,
мы
кашисты-мумпсисты
не стали комментировать это вульгарное сравнение из соображений
политкорректности
но Вы нарываетесь :
ведь понятно что условие q:d>20060227.9
выбирает по дням рождения с точностью до дня
а Ваше - до года
Напишите условие не "16 лет"
а "дети родившиеся в период 20060202-20060227 включительно"
и тогда считайте
23 фев 06, 10:06    [2384695]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
SergSuper

Вот объясните в чем разница. Допустим таже структура: Цех/Работник/Дети. Можно сделать это деревом и обращаться к этому условно $A('Литейный цех','Иванов','Вася').
А можно тоже самое представить таблицей с соответствующими полями и обращаться как select * from tbl where Цех='Литейный цех' and Работник='Иванов' and Дети='Вася'. Получается разница только в синтаксисе. Мне чего-то не уловить концепцию проектирования деревьями


Разница в образе мышления над проектами, уже на второй день работы с М языком (любой диалект).

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

Технический пример. Двумерная таблица по которой необходимо выполнять интерполяцию входной величины. Таблица с уступами справа и слева, вверху и внизу. Расстояние между колонками и рядами переменно. Что поделать, такова таблица. Это не прикол - это реальные экспериментальные данные.

Работа со справочниками типа СНИП.

И таких примеров масса.

Да и вообще, как бы обрадовались офисные работники, если бы Explorer, WinCommander и дригие вдруг потеряли бы древовидность. Даже если бы у них появились супер-навороченные select ..... where .....
23 фев 06, 12:54    [2385032]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
CesaTheGuest
Guest
select child from t1 where parent='Иванов' and BirthDate between '20020101' and '20061231' 
Думаю так сгодится... Уважаемые коллеги, спор о том, какой код будет короче, с моей точки зрения, абсолютно непринципиален, ибо в конечном итоге любой программер предпочтет наглядность (сопровождать легче). Если хотите поспорить - объявляйте все перменные и процедуры в своих проектах одной буквой. :) Я одного такого наблюдал... На фоне М инструкций вывод о легком начале для программера в М выглядит несколько бледно. Кроме того, выражение "деревьями проектировать удобно", тоже представляется сомнительном. Ибо деревьев реализованных на всеких РСУБД уже не счесть, и особо никто не жаловался, особенно, во многих диалектах SQL есть спец. инструкции для их обработке.
23 фев 06, 13:05    [2385050]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
SergSuper
[quot Rus000]3) Проектировать и кодировать на M можно быстро и эффективно, даже не сомневайтесь, однако требуется доп.интерфейсный инструментарий

Может быть.
Как-то просил кого-то (не помню кого, но он тоже про эффективность писал) показать на примере. Допустим есть такая структура - начальник- подчинённые, у каждого подчинённого могут быть свои подчиненные, вложенность неопределена. Требуется вывести список всех сотрудников вместе с суммарной зарплатой всех их подчинённых. Собственно я много кому эту задвчу предлагаю. Вроде типично иерархическая задача. На чистом SQL она решается не очень красиво. Хотелось бы посмотреть как она решается на языках учитывающих специфику древовидной организации данных . Никто из сторонников М так решения и не привёл. Если не трудно - было бы интересно посмотреть.
Rus000


легко:
s b="bbbb",c="ccccc",d="dddd",c="cccc",k="kkkk",z="zzzz",v="vvvv",x="xxxx"
s S(b)=5000
s S(b,c)=500
s S(b,c,d)=50
s S(b,k)=600
s S(b,c,d,z)=4
s S(b,k,v)=70
s S(b,c,x)=10
эти м-команды создали дерево "S" (зарплата).
например S(b,c,d)=50
-работник "dddd" получает 50.руб и подчиняется
начальнику "cccc" который подчиняется начальнику "bbbb"

теперь смотрим решение задачи на M в терминальном варианте :
======================================================
s A="S" k SS
f s A=$q(@A) q:A="" f N=1:1:$ql(A) s i=$qs(A,N),SS(i)=$g(SS(i))+@A
zw SS
======================================================

m+excel вариант см приложение

К сообщению приложен файл (zarplata.xls - 20Kb) cкачать
23 фев 06, 13:39    [2385126]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

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

Вот объясните в чем разница. Допустим таже структура: Цех/Работник/Дети. Можно сделать это деревом и обращаться к этому условно $A('Литейный цех','Иванов','Вася').
А можно тоже самое представить таблицей с соответствующими полями и обращаться как select * from tbl where Цех='Литейный цех' and Работник='Иванов' and Дети='Вася'. Получается разница только в синтаксисе. Мне чего-то не уловить концепцию проектирования деревьями


Разница в образе мышления над проектами, уже на второй день работы с М языком (любой диалект).

Представьте, необходимо доставить срочную телеграмму, полный адрес указан - значит идем по конкретному адресу. Неверно указана квартира, но до дома то мы идем по точному адресу, а там уже выполняем обход.
На первый взгляд действительно дерево. Но согласитесь тоже самое можно сделать на SQL - выбираем сначала по всем условиям, не получилось - некоторые убираем. Разница только в синтаксисе и терминологии, разницы в мышлении нет, во всяком случае я не вижу.
Я думаю как минимум 50% читающих сталкивались с проблеммой заполнения адресов по базе НИ. И не думаю что возникали особые трудности. Но только вы несколько идилическую катрину рисуете. Надо допустим заполнять регион, район, поселок, улицу, дом. А район часто не пишут. Придётся перебирать все районы, на SQL можно получить запросом всё подходящее.
AlexKB

Или планомерно, неторопясь, улица за улицей, дом за домом разносим себе почту.
select * from addr where city=... order by steet, house
AlexKB

Или необходимо занести в первый (последний) дом на каждой улице листовку. Мы не знаем заранее сколько улиц, какие они, какой номер дома на каждой улице первый (последний).
что может быть проще? select min(house), max(house) from addr where steet=...
AlexKB

Технический пример. Двумерная таблица по которой необходимо выполнять интерполяцию входной величины. Таблица с уступами справа и слева, вверху и внизу. Расстояние между колонками и рядами переменно. Что поделать, такова таблица. Это не прикол - это реальные экспериментальные данные.

Работа со справочниками типа СНИП.

И таких примеров масса.

ничё не понял.Как тут древовидное мышление может помочь?
AlexKB

Да и вообще, как бы обрадовались офисные работники, если бы Explorer, WinCommander и дригие вдруг потеряли бы древовидность. Даже если бы у них появились супер-навороченные select ..... where .....

Их радость была бы не полной, если б до этого они бы не писали s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
Не надо мешать представление в интерфейсе с реализацией

MX -- ALEX
s A="S" k SS
f s A=$q(@A) q:A="" f N=1:1:$ql(A) s i=$qs(A,N),SS(i)=$g(SS(i))+@A
zw SS

Мерси, но только можно небольшой комментарий? Мягко говоря ничего не понятно
23 фев 06, 14:05    [2385191]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить