Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
VoDAДа будет откровение: дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном). я тебя правильно понял? то есть даже после моего намека предыдущему оппоненту ты утверждаешь, что "циклов нет"? :) в М-системах, как я понял, хорошо работают запросы работающие в соответствии с деревом объектов. если запрос не попадает (не соответствует) дереву, то требуется полный-скан или ЗАРАНЕЕ построенное дерево (т.е. нужно поддерживать 2 или n деревьев для быстрой работы на различных запросах) народ, надо все-таки внимательнее читать, ага. который раз повторяю, что в M-системах нет фиксированных моделей структур. как и языка запросов к ним. все что нужно программисту - он делает самостоятельно. как он сформирует интерфейс между пользователем и БД, как спроектирует саму БД - так все это дело и будет работать. теперь о деревьях. в принципе, "реляционные модели" - тоже деревья. только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев", в РСУБД та же фигня. :) С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 03:50 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Опять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно! И не обязан работать на птичьих языках с дурацкой нотацией! Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ??? А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках. Прелесть просто, неограниченная свобода! Любую модель данных! Таблицы - да не проблема! Деревья - легко! Сетевую - влет! Вывод - соотношение цена/свобода просто замечательное! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 09:56 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
ну я 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 -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:04 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov VoDAДа будет откровение: дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном). я тебя правильно понял? то есть даже после моего намека предыдущему оппоненту ты утверждаешь, что "циклов нет"? :) НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:06 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
ggvОпять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно! И не обязан работать на птичьих языках с дурацкой нотацией! Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ??? А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках. Прелесть просто, неограниченная свобода! Любую модель данных! Таблицы - да не проблема! Деревья - легко! Сетевую - влет! Вывод - соотношение цена/свобода просто замечательное! хотелось бы из чисто маркетных соображений сделать вариант нашего МХ еще на чем нибудь кроме мумпса - например на BerkeleyDB вся бизнес логика и запросы к серверам данных у нас сидят в ячейках эксцел-листов на клиентах и при активизации листа выполняются однократно затем лист продолжает работать интерактивно - примерно как страничка при работе с интернетом в ячейку много не запихнешь - лучше не вылезать за 255 знаков мумпс как раз подходит - компактный он кроме того - интерпретатор и очень быстрый все работает красиво и просто НО минус - дороговато за лицензии MSM-CACHE (на бесплатном GTM-мумпсе работа только через линукс а бесплатный М3-мумпс - медленнее чем CACHE-MSM) Как Вы считаете - подойдет ли BerkeleyDB ? можно ли его разложить по ячейкам ексцел ? Спасибо ===================== ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:30 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
tygra Сколько работает csp - никто не знает. Никто вообще не слышал об этом чуде. Опять же смотря где. ;-))) Это вопрос распространенности и известности технологии. Где-то известна, где-то нет. Ничуть не сомневаюсь, что например в вашей конторе много лет используется какая-нибудь технология, о которой в нашей конторе никто даже названия не слышал. А с csp я работал, помнится, еще в 99-м. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:36 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Sergei Obrastsov VoDAДа будет откровение: дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном). я тебя правильно понял? то есть даже после моего намека предыдущему оппоненту ты утверждаешь, что "циклов нет"? :) НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа забавно. "а он все не понимает и не понимает..." :) ну хорошо: шаг № 1: я убираю все циклы по БД в программы шаг № 2: теперь запрос выглядит так: Код: plaintext 1. шаг № 3: я гордо заявляю: у меня в БД циклов нет! С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:38 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
ggvОпять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно! Вот по этой ссылочке есть критика Каше .. http://www.dimas.ru/ic/ic084.htm и в том числе про BerkeleyDB упоминается.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:47 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
>>Т.е. явно говорится, что без Кэша это все гроша ломаного не стоит. Вы совершенно правы - CSP (Cache Servers Pages) без Каше не может использоваться. Что Вас удивляет то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:50 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov,шаг № 3: я гордо заявляю: у меня в БД циклов нет! Дык и функционала теперь нет. Я чесно говоря, намёка не понял Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов Вы с этим не согласны? С приветом Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 10:52 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
SergSuper Sergei Obrastsov,шаг № 3: я гордо заявляю: у меня в БД циклов нет! Дык и функционала теперь нет. Какого функционала?! Все на месте. Я чесно говоря, намёка не понял Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов Вижу, что не понял. Не используешь. Используешь "мой вариант". Что тебе сказать? Один мой знакомый считает, что никакого "машинного кода" не существует и Windows - это самый нижний уровень. :) С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:09 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov Gluk (Kazan) Sergei Obrastsov VoDAДа будет откровение: дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном). я тебя правильно понял? то есть даже после моего намека предыдущему оппоненту ты утверждаешь, что "циклов нет"? :) НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа забавно. "а он все не понимает и не понимает..." :) ну хорошо: шаг № 1: я убираю все циклы по БД в программы шаг № 2: теперь запрос выглядит так: Код: plaintext 1. шаг № 3: я гордо заявляю: у меня в БД циклов нет! С уважением. Сергей НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах). Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:13 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazanшаг № 1: НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах). Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело. Среднему разработчику и не надо хвататься за M, ему хватит того, что настроено вокруг "реляционных таблиц". Он, кстати, и не лезет. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:19 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov я тебя правильно понял? то есть даже после моего намека предыдущему оппоненту ты утверждаешь, что "циклов нет"? :) народ, надо все-таки внимательнее читать, ага. который раз повторяю, что в M-системах нет фиксированных моделей структур. как и языка запросов к ним. все что нужно программисту - он делает самостоятельно. как он сформирует интерфейс между пользователем и БД, как спроектирует саму БД - так все это дело и будет работать. теперь о деревьях. в принципе, "реляционные модели" - тоже деревья. только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев", в РСУБД та же фигня. :) С уважением. СергейМожно повторить намек? И будьте добры объясните "реляционные модели" - тоже деревья, только двухуровневые . В каком смысле деревья? И что означает двухуровневые? PS спрашиваю не из стеба, просто интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:24 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
SergSuper Sergei Obrastsov,шаг № 3: я гордо заявляю: у меня в БД циклов нет! Дык и функционала теперь нет. Я чесно говоря, намёка не понял Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов Вы с этим не согласны? С приветом Сергей нет разработчик приложений на базе нормального м-инструментария может обходится без написания циклов , и, также как Вас, его не волнует, как м-сервер выполнит запрос (например qWORD СП-АРМ с.Петербург) (к разработчику м-инструментария конечно это не относится) без м-инструмента - только для изучения принципов мумпса или очень специальные задачи с очень высокими требованиями действительно не существует универсального бесплатного м-инструмента, но есть несколько специализированых, хорошо заточеных для своих областей. (А специальное разве не предпочтительнее универсального для серьезных дел :) например, наш MX заточен для задач класса "1с-предприятие" (циклов рисовать там вовсе не обязательно ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:25 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL. На самом деле это афера. Хочу услышать конструктивную критику по предложению. Создается две базы данных. Первая - обычная и основная - где выполняется вся логика программы. Вторая для хранения "вложеных таблиц". DB1. table1 id_row int id_data данные id_table_name имя таблицы в которой хранятся данные вложеной таблицы. DB2 id_table_name названия таблицы на котороу ссылается запись из первой базы и первой таблицы. Для каждой записи название будет генерироваться и оно будет уникальным потом сама струтктура таблицы. По логике, в этом случае вложеная таблица по структуре может отличаться от каждой записи masterid. Согласен - что выглядит все как-то криво, но думаю будет работать. Интересно какое ограничени на число таблиц в SQL ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:27 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei ObrastsovСреднему разработчику и не надо хвататься за M, ему хватит того, что настроено вокруг "реляционных таблиц". Он, кстати, и не лезет. Мним себя богами ??? ну ну, это бывает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:29 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov SergSuper Sergei Obrastsov,шаг № 3: я гордо заявляю: у меня в БД циклов нет! Дык и функционала теперь нет. Какого функционала?! Все на месте. Я чесно говоря, намёка не понял Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов Вижу, что не понял. Не используешь. Используешь "мой вариант". Что тебе сказать? Один мой знакомый считает, что никакого "машинного кода" не существует и Windows - это самый нижний уровень. :) С уважением. Сергей Какие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло MX -- ALEX разработчик приложений на базе нормального м-инструментария может обходится без написания циклов Уточните пожалуйста: "может обходится" или "обычно обходится"? Iura Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL. Я бы посоветовал пообщаться со специалистами по БД или дать задание на разработку БД кому-то другому. Идея спорная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:47 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Sergei ObrastsovСреднему разработчику и не надо хвататься за M, ему хватит того, что настроено вокруг "реляционных таблиц". Он, кстати, и не лезет. Мним себя богами ??? ну ну, это бывает :) думаю Сергей имел в виду следующее 1- начать работать на мумпсе с нуля сложнее - мало литературы мало где используется гораздо чаще студент натыкается на SQL и пошло - поехало на всю оставшуюся жизнь - эффект вылупившегося утенка - кого первым увидел - тот и родитель применить нестандарное решение - мумпс - отважится только матерый программист (и не пожалеет) 2- все программисты - умные но есть многодетные матери которым глубоко копать просто нет времени им лучше что попроще (хотя повторяю- с хорошим м-инструментом прекрасно работают даже начинающие и многодетные) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 11:54 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
SergSuper MX -- ALEX - разработчик приложений на базе нормального м-инструментария может обходится без написания циклов Уточните пожалуйста: "может обходится" или "обычно обходится"? у нас в М есть встроенный генератор отчетов и поисковик 90 % задач решается путем составления запросов без циклов нестандартные задачи - например увязка с АСУТП потребовали спец програмирования с циклами опроса датчиков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:02 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
VoDAМожно повторить намек? проще его прочитать в моем письме где-то выше. впрочем, повторюсь: есть там циклы, никуда они не денутся, только этим занимается сервер. но это же не повод гордиться "отсутствием циклов", ага :) И будьте добры объясните "реляционные модели" - тоже деревья, только двухуровневые . В каком смысле деревья? И что означает двухуровневые? PS спрашиваю не из стеба, просто интересно верю. таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если нарисовать (особенно отношение "1:any"). :) почему только два уровня? потому что такие таблицы, там только одно отношение. если индекс составной, то он скомбинирован. так он выглядит логически, так он сделан и физически. за исключением исходных данных, там только один уровень (номер записи) С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:07 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
MX -- ALEX у нас в М есть встроенный генератор отчетов и поисковик 90 % задач решается путем составления запросов без циклов нестандартные задачи - например увязка с АСУТП потребовали спец програмирования с циклами опроса датчиков Странно Вот приводились решения простых задач, в частности и Вами - и все сплошь на циклах... Т.е. у вас есть какие-то наработки и вы с уровня писания циклов ушли. Но ведь можно было бы и начинать с более высокого уровня... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:10 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov шаг № 1: я убираю все циклы по БД в программы 1 Раз циклы написал проггер, разрабатывающий логику приложения, а не само СУБД, то этот факт не уберешь. 2 Циклы по БД в программе - нужно уточнять хде они были раньше (они вседа в той или иной программе). Sergei Obrastsov шаг № 2: теперь запрос выглядит так: Теперь это и не вызов проги, но и как ассоциативный запрос тоже не выглядит. К тому же на SQL все кот его знают сразу поймут что за запрос, а тут нужны дополнительные усилия по поиску в программе циклов, шобы понять о чем речь. Sergei Obrastsov шаг № 3: я гордо заявляю: у меня в БД циклов нет! А они у Вас были в БД? Обыкновенно в БД данные. Ну ХП там хранятся. Ну даже сами проги, но тока хранятся. Нужно теперь уточнять чем Вы гордитесь теперь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:16 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
SergSuperКакие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло да бога ради. ну устраивает тебя SQL - так и работай на нем. меня в некоторых случаях, как например в приведенном мною, не устраивает. тогда я ищу другие решения. разве я хаю SQL? нет, просто в данном случае мне он не подходит. SergSuper MX -- ALEX разработчик приложений на базе нормального м-инструментария может обходится без написания циклов Уточните пожалуйста: "может обходится" или "обычно обходится"? может. если инструментарий есть. но это не значит, что циклов нет вообще. они просто проходят по уровню инструментария. :) С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:30 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov >>верю. таблицы легко представляются в "деревьях", Было уже, проходили и не раз. И даже на этом форуме. Если всё так легко, то представте мне пожалуйста таблицу с тремы столбцами (остальные можно опустить как несущественные) 1. ТИП ДОКУМЕНТА 2. ДАТА ОПЕРАЦИИ 3. СУММА ИМХО, типичный набор для любой учётной задачи. Ессс-но нужно что бы поиск по ЛЮБОМУ из полей или ЛЮБОЙ ИХ КОМБИНАЦИИ был оптимальным и не сильно зависел от кардинальности. >>первый уровень - индекс, второй - номер записи. А что такое "НОМЕР ЗАПИСИ" ? >>почему "дерево"? потому что похоже на елку, если нарисовать (особенно отношение "1:any"). :) почему только два уровня? потому что такие таблицы, там только одно отношение. если индекс составной, то он скомбинирован. Нифига не понял почему уровня 2, и кому такое дерево нафиг нужно.... >>так он выглядит логически, так он сделан и физически. Как ТАК ? Физически похожим на ёлку ? >>за исключением исходных данных, там только один уровень (номер записи) Если уровень в дереве только ОДИН это уже список а не дерево. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2006, 12:31 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33709335&tid=1553519]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 365ms |

| 0 / 0 |
