Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 19   вперед  Ctrl
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
VoDA
Да будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


в М-системах, как я понял, хорошо работают запросы работающие в соответствии с деревом объектов.
если запрос не попадает (не соответствует) дереву, то требуется полный-скан или ЗАРАНЕЕ построенное дерево (т.е. нужно поддерживать 2 или n деревьев для быстрой работы на различных запросах)

народ, надо все-таки внимательнее читать, ага. который раз повторяю, что
в M-системах нет фиксированных моделей структур. как и языка запросов
к ним. все что нужно программисту - он делает самостоятельно. как он
сформирует интерфейс между пользователем и БД, как спроектирует саму
БД - так все это дело и будет работать.

теперь о деревьях. в принципе, "реляционные модели" - тоже деревья.
только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев",
в РСУБД та же фигня. :)

С уважением. Сергей
5 май 06, 03:50    [2632385]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ggv
Member

Откуда:
Сообщений: 1810
Опять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!
И не обязан работать на птичьих языках с дурацкой нотацией!
Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ???
А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках.
Прелесть просто, неограниченная свобода!
Любую модель данных!
Таблицы - да не проблема!
Деревья - легко!
Сетевую - влет!
Вывод - соотношение цена/свобода просто замечательное!
5 май 06, 09:56    [2632810]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
ну я
SergSuper
Слова "только" нет, но смысл такой есть:
Один из основных недостатков традиционных средств разработки Web-приложений - необходимость перезагрузки всей страницы, если нужно измененить содержимое ее части. JavaScript, Объектная модель документа и Динамический HTML решают эту проблему, но только отчасти. Они позволяют изменять содержимое страницы динамически, но не избавляют от необходимости полной перезагрузки страницы в случае, когда необходимо отобразить в браузере данные из СУБД.

Согласен, тут они лажанули. Гонят. Особенно в выделенном жирным. И к серверу это никак не относится.

Ну как же не относится?
Вот абзац оттуда же
автор
Для разработки Web-приложений в Caché используется технология серверных страниц, т.е. создаются специальные страницы, которые заполняются данными немедленно ("on-the-fly"), как только они запрашиваются браузером. Отличие серверных страниц Caché (Caché Server Pages) от других технологий разработки Web-приложений состоит в том, что они хранятся на сервере данных Caché, так сказать, рядом с используемыми данными.

Т.е. явно говорится, что без Кэша это все гроша ломаного не стоит.

автор
Я понял. Аякс есть. Ты (или Вы) приписали лишнее слово. Но это уже самовнушение. Нет там слова "только". А что касается аякса - так ему без году неделя, а csp работает уже сколько лет.

Сколько работает csp - никто не знает. Никто вообще не слышал об этом чуде.
автор
Поясню - для кашистов просто странно слышать про аякс как про нечто новое. Дело не в том, лучше это или хуже, а в том что сильно ломает кидаться на альтернативы если они не дают ничего нового. А переплюнуть возможности csp (это сокращение от cache server pages) будет тяжеловато.

А для не-кашистов - слышать вообще про кэш и csp это что-то новое и переплюнуть csp тяжело, потому что никто их не видел. И, как вы и сказали, сильно ломает кидаться на альтернативы если они не дают ничего нового
Или это такая навороченная программа распротсранения продукта - чтобы никто ничего не знал, а кто как-то узнает, тот и купит может быть :) Программа удачная надо сказать - мало кто слышал про Кэш вообще а про csp уж вообще никто наверное, кроме нескольких человек :)

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

А колеса вы Кэшом не накачиваете?
Т.е. то, что СУБД используют для чего непопадя из-за неумения это сделать по-человечески, это огрооооомный плюс?

======
Еще вернемся к маркетинговым материалам - добьем собачку :)
автор
В основе Caché лежит транзакционная многомерная модель данных (TMDMTM), которая позволяет хранить и представлять данные так, как они чаще всего используются. TMDM снимает все ограничения, накладываемые двумерными реляционными моделями данных, ведь если реляционная модель состоит из большого количества таблиц, что необходимо при работе со сложными структурами данных, это существенно усложняет и замедляет выполнение сложных транзакций и ведет к хранению излишней информации.

Огласите весь список пожалста того, что выделено красным - а то я работаю и не знаю, что можно еще во-много раз быстрее и проще и что щастте где-то рядом :)
Если конечно кто знает, о чем говорится

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

Ай-ай-ай, даже попытки ведут к неуду, а если уже не попытки а промышленное использование - производительность в минус должна уйти?

Пример.
Есть Клиент, Заказ, Адрес, Товары вообще, Товары заказа.
Если я храню это все в отдельных пяти таблицах - это плохо
Если я храню это в пяти объектах Кэша - это хорошо.
Вопрос - чем это хорошо?
И еще вопрос - найти клиентов у которых заказы имеют такие-то товары мне раз плюнуть.
Как это делать в Кэшэ? Придется строить обратные индексы?

=======

Весело тут у нас :)

-- Tygra's --
5 май 06, 10:04    [2632856]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
VoDA
Да будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа
5 май 06, 10:06    [2632872]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
ggv
Опять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!
И не обязан работать на птичьих языках с дурацкой нотацией!
Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ???
А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках.
Прелесть просто, неограниченная свобода!
Любую модель данных!
Таблицы - да не проблема!
Деревья - легко!
Сетевую - влет!
Вывод - соотношение цена/свобода просто замечательное!


хотелось бы из чисто маркетных соображений
сделать вариант нашего МХ еще на чем нибудь
кроме мумпса - например на BerkeleyDB

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

в ячейку много не запихнешь - лучше не вылезать за 255 знаков
мумпс как раз подходит - компактный
он кроме того - интерпретатор и очень быстрый
все работает красиво и просто
НО
минус - дороговато за лицензии MSM-CACHE
(на бесплатном GTM-мумпсе работа только через линукс
а бесплатный М3-мумпс - медленнее чем CACHE-MSM)

Как Вы считаете - подойдет ли BerkeleyDB ?
можно ли его разложить по ячейкам ексцел ?

Спасибо
=====================
5 май 06, 10:30    [2633007]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

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

Сколько работает csp - никто не знает. Никто вообще не слышал об этом чуде.

Опять же смотря где. ;-))) Это вопрос распространенности и известности технологии. Где-то известна, где-то нет. Ничуть не сомневаюсь, что например в вашей конторе много лет используется какая-нибудь технология, о которой в нашей конторе никто даже названия не слышал. А с csp я работал, помнится, еще в 99-м.
5 май 06, 10:36    [2633063]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Sergei Obrastsov
VoDA
Да будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа

забавно. "а он все не понимает и не понимает..." :)
ну хорошо:

шаг № 1:
я убираю все циклы по БД в программы

шаг № 2:
теперь запрос выглядит так:
     s Result = $$Select^server(x1,x2...)

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

С уважением. Сергей
5 май 06, 10:38    [2633079]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
ggv
Опять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!


Вот по этой ссылочке есть критика Каше ..
http://www.dimas.ru/ic/ic084.htm
и в том числе про BerkeleyDB упоминается..
5 май 06, 10:47    [2633167]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>Т.е. явно говорится, что без Кэша это все гроша ломаного не стоит.

Вы совершенно правы - CSP (Cache Servers Pages) без Каше не может использоваться. Что Вас удивляет то?
5 май 06, 10:50    [2633191]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergei Obrastsov,
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

Дык и функционала теперь нет.

Я чесно говоря, намёка не понял

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

Вы с этим не согласны?

С приветом Сергей
5 май 06, 10:52    [2633209]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Sergei Obrastsov,
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

Дык и функционала теперь нет.

Какого функционала?! Все на месте.


Я чесно говоря, намёка не понял
Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вижу, что не понял. Не используешь. Используешь "мой вариант".
Что тебе сказать? Один мой знакомый считает, что никакого "машинного
кода" не существует и Windows - это самый нижний уровень. :)

С уважением. Сергей
5 май 06, 11:09    [2633331]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Gluk (Kazan)
Sergei Obrastsov
VoDA
Да будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа

забавно. "а он все не понимает и не понимает..." :)
ну хорошо:

шаг № 1:
я убираю все циклы по БД в программы

шаг № 2:
теперь запрос выглядит так:
     s Result = $$Select^server(x1,x2...)

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

С уважением. Сергей


НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах).
Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело.
5 май 06, 11:13    [2633368]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazanшаг № 1:

НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах).
Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело.

Среднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.

С уважением. Сергей
5 май 06, 11:19    [2633420]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Sergei Obrastsov

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)

народ, надо все-таки внимательнее читать, ага. который раз повторяю, что
в M-системах нет фиксированных моделей структур. как и языка запросов
к ним. все что нужно программисту - он делает самостоятельно. как он
сформирует интерфейс между пользователем и БД, как спроектирует саму
БД - так все это дело и будет работать.

теперь о деревьях. в принципе, "реляционные модели" - тоже деревья.
только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев",
в РСУБД та же фигня. :)

С уважением. Сергей
Можно повторить намек?

И будьте добры объясните "реляционные модели" - тоже деревья,
только двухуровневые
. В каком смысле деревья? И что означает двухуровневые?

PS спрашиваю не из стеба, просто интересно
5 май 06, 11:24    [2633467]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
SergSuper
Sergei Obrastsov,
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

Дык и функционала теперь нет.

Я чесно говоря, намёка не понял

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

Вы с этим не согласны?

С приветом Сергей


нет

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

(к разработчику м-инструментария конечно это не относится)

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

действительно не существует универсального бесплатного
м-инструмента, но есть несколько специализированых,
хорошо заточеных для своих областей.
(А специальное разве не предпочтительнее универсального
для серьезных дел :)
например, наш MX заточен для задач класса "1с-предприятие"
(циклов рисовать там вовсе не обязательно )
5 май 06, 11:25    [2633474]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL.

На самом деле это афера. Хочу услышать конструктивную критику по предложению.

Создается две базы данных.
Первая - обычная и основная - где выполняется вся логика программы.
Вторая для хранения "вложеных таблиц".

DB1.

table1
id_row int
id_data данные
id_table_name имя таблицы в которой хранятся данные вложеной таблицы.

DB2
id_table_name названия таблицы на котороу ссылается запись из первой базы и первой таблицы. Для каждой записи название будет генерироваться и оно будет уникальным
потом сама струтктура таблицы.

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

Согласен - что выглядит все как-то криво, но думаю будет работать.
Интересно какое ограничени на число таблиц в SQL ?
5 май 06, 11:27    [2633485]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Среднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.


Мним себя богами ???
ну ну, это бывает :)
5 май 06, 11:29    [2633501]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergei Obrastsov
SergSuper
Sergei Obrastsov,
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

Дык и функционала теперь нет.

Какого функционала?! Все на месте.


Я чесно говоря, намёка не понял
Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вижу, что не понял. Не используешь. Используешь "мой вариант".
Что тебе сказать? Один мой знакомый считает, что никакого "машинного
кода" не существует и Windows - это самый нижний уровень. :)

С уважением. Сергей

Какие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло

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

Уточните пожалуйста: "может обходится" или "обычно обходится"?

Iura

Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL.

Я бы посоветовал пообщаться со специалистами по БД или дать задание на разработку БД кому-то другому.
Идея спорная
5 май 06, 11:47    [2633639]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
Gluk (Kazan)
Sergei Obrastsov
Среднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.


Мним себя богами ???
ну ну, это бывает :)


думаю Сергей имел в виду следующее

1- начать работать на мумпсе с нуля сложнее - мало литературы
мало где используется
гораздо чаще студент натыкается на SQL и пошло - поехало на всю
оставшуюся жизнь - эффект вылупившегося утенка - кого
первым увидел - тот и родитель
применить нестандарное решение - мумпс -
отважится только матерый программист
(и не пожалеет)

2- все программисты - умные
но есть многодетные матери которым глубоко копать
просто нет времени
им лучше что попроще

(хотя повторяю- с хорошим м-инструментом прекрасно
работают даже начинающие и многодетные)
5 май 06, 11:54    [2633709]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
SergSuper

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

Уточните пожалуйста: "может обходится" или "обычно обходится"?


у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков
5 май 06, 12:02    [2633803]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
VoDA
Можно повторить намек?

проще его прочитать в моем письме где-то выше.
впрочем, повторюсь: есть там циклы, никуда они не денутся, только
этим занимается сервер. но это же не повод гордиться "отсутствием
циклов", ага :)


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

верю. таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.
так он выглядит логически, так он сделан и физически.
за исключением исходных данных, там только один уровень (номер записи)

С уважением. Сергей
5 май 06, 12:07    [2633855]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
SergSuper
Member

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

у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков

Странно
Вот приводились решения простых задач, в частности и Вами - и все сплошь на циклах...

Т.е. у вас есть какие-то наработки и вы с уровня писания циклов ушли. Но ведь можно было бы и начинать с более высокого уровня...
5 май 06, 12:10    [2633893]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
vadiminfo
Member

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

шаг № 1:
я убираю все циклы по БД в программы

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

Sergei Obrastsov

шаг № 2:
теперь запрос выглядит так:

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

Sergei Obrastsov

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

А они у Вас были в БД? Обыкновенно в БД данные. Ну ХП там хранятся. Ну даже сами проги, но тока хранятся. Нужно теперь уточнять чем Вы гордитесь теперь.
5 май 06, 12:16    [2633938]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Какие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло

да бога ради. ну устраивает тебя SQL - так и работай на нем. меня в некоторых
случаях, как например в приведенном мною, не устраивает.
тогда я ищу другие решения. разве я хаю SQL? нет, просто в данном случае
мне он не подходит.

SergSuper

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

Уточните пожалуйста: "может обходится" или "обычно обходится"?

может. если инструментарий есть. но это не значит, что циклов нет вообще.
они просто проходят по уровню инструментария. :)

С уважением. Сергей
5 май 06, 12:30    [2634057]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Sergei Obrastsov
>>верю. таблицы легко представляются в "деревьях",

Было уже, проходили и не раз. И даже на этом форуме.
Если всё так легко, то представте мне пожалуйста таблицу с тремы столбцами (остальные можно опустить как несущественные)

1. ТИП ДОКУМЕНТА
2. ДАТА ОПЕРАЦИИ
3. СУММА

ИМХО, типичный набор для любой учётной задачи.
Ессс-но нужно что бы поиск по ЛЮБОМУ из полей или ЛЮБОЙ ИХ КОМБИНАЦИИ был оптимальным и не сильно зависел от кардинальности.


>>первый уровень - индекс, второй - номер записи.

А что такое "НОМЕР ЗАПИСИ" ?

>>почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.

Нифига не понял почему уровня 2, и кому такое дерево нафиг нужно....

>>так он выглядит логически, так он сделан и физически.

Как ТАК ? Физически похожим на ёлку ?

>>за исключением исходных данных, там только один уровень (номер записи)

Если уровень в дереве только ОДИН это уже список а не дерево.
5 май 06, 12:31    [2634066]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить