Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 81 82 83 84 85 [86] 87 88 89 90 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Кстати вопрос - на что это "другое" мы переходим ?

>>А теперь представьте, что вам потребовался новый индекс, это в промышленности бывает на каждом шагу

Неверно. Это бывает на каждом шагу в РУСБД.

Давайте лучше представим (оссобенно если вы требуете откинуть всё надстройки из обсуждения вопроса.) - зачем нам потребовался этот индекс.

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

На выходе у нас "необходимость добавления индекса" на входе ??? ... вашу причину озвучьте плииз.
11 янв 07, 11:11    [3625535]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

То что они как М не существуют внутри СУБД IMXO сказывается куда сильнее в данном вопросе - и опять же вы всё таки просто хотите услышать что М не СУБД.

Учитывая, что я подчркивал, что не сомневаюсь, что Каша СУБД, ясно что я спрашивал именно про М, раз Я сомневаюсь что М СУБД.

А Вы отвечая про М говорите
Ptn

Хорошо .. давайте - всё сказанное мной относится к Каше.


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

И Вы как бы косвенно подтверждаете что там нет РМД.
Ptn


Можно зайти с другой стороны
MSM, DTM, GT.M - там нет SQL - можно ли их считать СУБД ? IMXO можно.

Т.Е. в М нет любой МД.


Ptn

М это как Java.
- язык
- технология
- платформа

Java ни в каком смысле не СУБД. И когда говорят про платформы, технолгии, и т.д. обычно все таки говорят Java-технология, Java-платформа, а когда просто Java, то в 90%, думаю, имеют в виду язык.
11 янв 07, 11:46    [3625894]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
????????
Guest
vadiminfo
Стал быть там должна быть и МД. Вот про эту, а не Кашинскую МД и был вопрос.
Она в лучшем случае (если М СУБД) иерархическая, насколько мне казалось из всех здесь текстов.
Но некоторые мумпсисты на это эмоциально реагируют. Я и хотел прояснить в сухом остатке, очистив это эмоций.
Никаких РМД, ООМД там не было.
В ходьшем - плоская МД (М не СУБД). Т.е. там данные, которые без клиента просто набор байтов.

Можно пару слов на тему, что такое МД?
Если у меня есть dbf файл, программка которая его читает и пишет, то что именно в ней или в нем будет МД и которой?
11 янв 07, 11:55    [3625962]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
автор
Давайте лучше представим (оссобенно если вы требуете откинуть всё надстройки из обсуждения вопроса.) - зачем нам потребовался этот индекс.


давайте лучше скажем вот что:

- M хранит данные в "индексном" виде. Т.е. разработчик, разрабатывая модель хранения прикладных данных, сразу ориентируется, как он их будет хранить в этих индексах.

- РСУБД вообще не оперирует понятием "индекс" с точки зрения SQL. Индексы являются внутренним средством соблюдения ограничений PK, FK, Unique или ускорения ряда операций - поиск, join, группировка, выборка в упорядоченном виде и т.п.

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

Мне, как человеку, достаточно плотно работавшему с М и работающему с РСУБД это понятно. А Вам?
11 янв 07, 12:25    [3626252]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
????????
Можно пару слов на тему, что такое МД?
Если у меня есть dbf файл, программка которая его читает и пишет, то что именно в ней или в нем будет МД и которой?

Думаю, в Вашем случае, вопрос МД не актуален. Цели не оправдываю средства: МД имеет значение для проектирования БД, сопровождения БД, понимания ее содержания. У вас все в программке в основном.
Формально у Вас поддерживается формат файла, с которым могут работать РСУБД. Т.е. реляционный формат.
Но конкретно Ваша система - файловая - Без СУБД. Считайте ее полской МД, т.е. забейте на это аспект.
11 янв 07, 12:31    [3626324]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo Трабла то в чем? М язык, который, насколько я понимаю позволяет сохранять данные перманенто.Т.е. типа в языке есть такие команды. И сохраненные данные c точки зрения некоторых мумпсистов - это БД.

В языке есть сохранение данных в БД, чтение данных из БД, транзакции и блокировки, команды доступа к физическим блокам БД, причем всё это может примянятся к нескольким физическим cache.dat в одном кусе кода - это всё относить М к СУБД.

Я возможно заблуждаюсь, но покажите мне в SQL блокировку, или чтение блоков - это задача Системы Управления БД.

>>Стал быть там должна быть и МД. Вот про эту, а не Кашинскую МД и был вопрос.

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

>>Никаких РМД, ООМД там не было.
В М небыло.

>>В ходьшем - плоская МД (М не СУБД). Т.е. там данные, которые без клиента просто набор байтов.
В любой БД это так - или вы SQL-консоль за клиента не считаете ?

>>И Вы как бы косвенно подтверждаете что там нет РМД.
Конкретно в М - стандартном не заложено - но модель данных РМД я на нем могу реализовать - а конкретно Каше итак уже это сделала за меня.

>>Т.Е. в М нет любой МД.
Как я пытался объяснить выше свою позицию - всё это зависит от точки зрения.
Если рассматривать М как язык то да - если как СУБД то нет.

Java ни в каком смысле не СУБД. И когда говорят про платформы, технолгии, и т.д. обычно все таки говорят Java-технология, Java-платформа, а когда просто Java, то в 90%, думаю, имеют в виду язык.

Мы говорим М о конкретном куске кода, и говорим М-система когда подразумеваем то где этот кусок кода имеет смысл.
И когда нас(мупсеров и кашистов) спрашивают на чем это написано/работает/реализовано - мы отвечаем на М.
11 янв 07, 12:37    [3626375]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зет
Guest
kdv
Мне, как человеку, достаточно плотно работавшему с М и работающему с РСУБД это понятно. А Вам?


Вы повторили то что я и так знаю :) Беда в том что вопрос не про это.

Вопрос развернуто звучит так:

Откуда к М-задаче взялось условие добавления нового индекса ?

Который распадается на два - какая была ...

1 Причина - побудившая к созданию нового индекса в РУСБД.
2 Причина - побудившая к созданию нового индекса в М.

Как человеку достаточно плотно работавшему с М Вы должны понимать что причины эти разные.

После выяснения причин Я задам следующий вопрос - о Задачах.

1. Какая задача породила Причину 1 в РУСБД.
2. Какая задача породила Причину 2 в М.

Как человека, достаточно плотно работавшему с М, это наводить вас на какие-нибудь мысли ?
11 янв 07, 12:46    [3626448]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Ч0рт - пропечатался - MIB2 а опасности
11 янв 07, 12:47    [3626457]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

И Вы как бы косвенно подтверждаете что там нет РМД.

Да нет никакой траблы, а есть просто непривычность для человека, прожившего сознательную жизнь в рамках конкретной модели.
ЧАЛ прав, в M нет никакой модели, но есть возможности для реализации любой.
Что до Cache, то там реализованы, средствами M, конечно, объектная и реляционная. Можно много спорить о том, насколько качественно это сделано, но уж сделано по крайней мере.
Возвращаясь к разговору о Cache и M, замечу, что Cache - это реализация M-стандарта, который касается не только языка M, как такового, но и организации средств хранения данных, равно и как доступа к ним, работы с устройствами и внутренними
процессами, поддержки многозадачности и много еще чего.
11 янв 07, 12:48    [3626461]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
автор
1. Какая задача породила Причину 1 в РУСБД.


ускорение поиска по столбцу или организация ограничения FK или UNIQUE

2. Какая задача породила Причину 2 в М.

аналогичная. например, поиск по значению "столбца", который где-то там в значении элемента глобали находится. Вроде как ^A(index) ='FIELD1!FIELD2!...', а нужно сделать возможность быстрого поиска по FIELD1. Значит, например, ^A('FIELD1', field1_value)=index. Или вообще ^B(field1_value)=index.

при этом, замечу, что если разработчику РСУБД после создания индекса по столбцу больше не надо делать вообще ничего, то разработчику на M нужно в программе для такого поиска организовать цикл с перебором $o по этому самому ^A('FIELD1'.... Т.е. разработчик на М делает то, что в РСУБД делается автоматически и прозрачно.
11 янв 07, 13:03    [3626577]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
н-да...
Guest
vadiminfo
????????
Можно пару слов на тему, что такое МД?
Если у меня есть dbf файл, программка которая его читает и пишет, то что именно в ней или в нем будет МД и которой?

Думаю, в Вашем случае, вопрос МД не актуален. Цели не оправдываю средства: МД имеет значение для проектирования БД, сопровождения БД, понимания ее содержания. У вас все в программке в основном.
Формально у Вас поддерживается формат файла, с которым могут работать РСУБД. Т.е. реляционный формат.
Но конкретно Ваша система - файловая - Без СУБД. Считайте ее полской МД, т.е. забейте на это аспект.

dbf - реляционный формат?
Сижу втыкаю. Ну, табличный - это еще может быть. Но чтобы формат был реляционным...
Н-да... Нашел у кого сросить.
11 янв 07, 13:06    [3626610]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
kdv
автор
1. Какая задача породила Причину 1 в РУСБД.


ускорение поиска по столбцу или организация ограничения FK или UNIQUE

2. Какая задача породила Причину 2 в М.

аналогичная. например, поиск по значению "столбца", который где-то там в значении элемента глобали находится. Вроде как ^A(index) ='FIELD1!FIELD2!...', а нужно сделать возможность быстрого поиска по FIELD1. Значит, например, ^A('FIELD1', field1_value)=index. Или вообще ^B(field1_value)=index.

при этом, замечу, что если разработчику РСУБД после создания индекса по столбцу больше не надо делать вообще ничего, то разработчику на M нужно в программе для такого поиска организовать цикл с перебором $o по этому самому ^A('FIELD1'.... Т.е. разработчик на М делает то, что в РСУБД делается автоматически и прозрачно.


Как человек долгое время работавший с М - вы меня удивляете.

1 - Совершенно верно - ускорение - которое потребовала задача выполнения некого запроса.

Как вы совершенно справедливо заметили в РУСБД не оперирует понятием "индекс"
Они нужны только для запросов.
Для выпоплнения запросов на языке РУСБД - он же SQL или его вариации.

Но проблема в том что М не оперирует понятием "запрос".

2. Неверно - это НЕ причина - это уже задача.

И такая задача в М - как таковая отсекается на этапе проектирования. На котором в структуре данных должны быть отработаны всё типовые запросы.

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

Как например я строил "индекс" в примере для Изопропила.

Как делает таже РУСБД при выполнении запросов c группировками сортировками и хэвингами.

Так с какого лешего задача нетипичного запроса приравнивается к ошибке в проектировании структуры данных ?

Ибо если запрос типовой, а "индекса", или обходного пути, нет - то грош цена такому проектировщику.

Про то что в М приходится делать больше движений руками никто и не спорить.

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

Он работает с уже упорядоченными, с определенным умыслом, данными .

И следовательно трудоемкость у "запроса" другая. И ИМХО преувеличенная.

Никто в М не будет корёжит структуру данных для НЕтиповых запросов.
11 янв 07, 13:25    [3626775]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
н-да...
dbf - реляционный формат?
Сижу втыкаю. Ну, табличный - это еще может быть. Но чтобы формат был реляционным...
Н-да... Нашел у кого сросить.

Таблицы то разные бывают. Многих возможных таблов формат dbf, скорее всего, не поддерживает. Среди таблов них выделяют реляционные таблы.
Впрочем, вопросы про dbf с удовольствием переадресовываю Вам. Исторические вопросы ИТ я пока отложил до лучших времен.
11 янв 07, 13:42    [3626935]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
H5N1
Guest
vadiminfo

Таблицы то разные бывают. Многих возможных таблов формат dbf, скорее всего, не поддерживает. Среди таблов них выделяют реляционные таблы.

а реляции то откуда в dbf ? :)
11 янв 07, 13:44    [3626966]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
автор
Но проблема в том что М не оперирует понятием "запрос".

как бы, я в курсе.

автор
2. Неверно - это НЕ причина - это уже задача.

И такая задача в М - как таковая отсекается на этапе проектирования. На котором в структуре данных должны быть отработаны всё типовые запросы.


ну начинается... и что, на этапе проектирования все сразу известно? Не бывает изменений? А потом, в процессе, тоже изменений не бывает? Сказки не надо рассказывать.
11 янв 07, 13:57    [3627084]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

а реляции то откуда в dbf ? :)

Про реляции не в курсе. В dbf поддерживается формат таблов, которые моно считать реляционными. По структуре и по возможности выполнять к ним операции из РМД.
Вопрос будет ли кто считать Дибайс, Клиппер СУБД или РСУБД меня не интересовал.
Могу сказать, что термин реляционный формат упоминается наприме в ROLAP (реляционны ОЛАП по простому). Т.е. не яго придумал.
По моему, он говорит о главной особенности формата. Впрочем, не настаиваю. Не хотите считать формат dbf реляционным, считайте табличным. Теперь тот кто спросил не сможет сказать, что у него нет выбора.
11 янв 07, 13:59    [3627102]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
автор
2. Неверно - это НЕ причина - это уже задача.

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

Для М этот пример приведен потому, что в нем без изменения приложения такое невозможно. Конечно, ответ вроде "такого не может быть потому что на этапе проектирования на М уже все учтено", но так не бывает. Бизнес развивается, что-то меняется, что-то добавляется. Разумеется, система X на предприятии может проработать несколько лет без изменений. Но это не показатель. Для такой же системы на РСУБД тоже не придется ничего менять.
11 янв 07, 14:02    [3627118]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
kdv
ну начинается... и что, на этапе проектирования все сразу известно? Не бывает изменений? А потом, в процессе, тоже изменений не бывает? Сказки не надо рассказывать.


Я не рассказываю сказки - я знаю что всего предусмотреть нельзя.

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

Просто повторюсь.

kdv
Так с какого лешего задача нетипичного запроса приравнивается к ошибке в проектировании структуры данных ?


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

Почему РУСБД-ники сразу из этого делают вывод что мупсерам нужно будет де исправлять основную программу - именно её и только её.

РУСБД-ники напишут запрос - мупсеры напишут процедуру с локальным индексом - и фсё !!!
11 янв 07, 14:09    [3627172]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
kdv
Для М этот пример приведен потому, что в нем без изменения приложения такое невозможно.


Интересно почему ?
Наверное мупсеры никогда не слышали о генераторах или о хуках для расширения функионала что ли ?
11 янв 07, 14:26    [3627321]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
В РСУБД так же могут логику описывать хранимыми процедурами, а могут и намертво вшивать в клиента, и всё привет - подправил запрос - компиляй клиента.

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

Да и тюнинг тут причем ? При тюнинге вы запрос не меняете.

Почему он должен меняться у мупсеров - если его при проектировании отюнинговали ?

Давайте не будем забывать оговорку про отбрасывание надстроек.
11 янв 07, 14:34    [3627383]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
н-да...
Guest
vadiminfo
H5N1

а реляции то откуда в dbf ? :)

Про реляции не в курсе. В dbf поддерживается формат таблов, которые моно считать реляционными. По структуре и по возможности выполнять к ним операции из РМД.
Вопрос будет ли кто считать Дибайс, Клиппер СУБД или РСУБД меня не интересовал.
Могу сказать, что термин реляционный формат упоминается наприме в ROLAP (реляционны ОЛАП по простому). Т.е. не яго придумал.
По моему, он говорит о главной особенности формата. Впрочем, не настаиваю. Не хотите считать формат dbf реляционным, считайте табличным. Теперь тот кто спросил не сможет сказать, что у него нет выбора.

Вадим, пиши еще )))) Четверг обычно скучный день )))
11 янв 07, 15:03    [3627637]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31621
Ptn

Почему РУСБД-ники сразу из этого делают вывод что мупсерам нужно будет де исправлять основную программу - именно её и только её.

РУСБД-ники напишут запрос - мупсеры напишут процедуру с локальным индексом - и фсё !!!


Вот почему
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=79#3614088
11 янв 07, 15:59    [3628160]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Изопропил
Ptn

Почему РУСБД-ники сразу из этого делают вывод что мупсерам нужно будет де исправлять основную программу - именно её и только её.

РУСБД-ники напишут запрос - мупсеры напишут процедуру с локальным индексом - и фсё !!!


Вот почему
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=79#3614088

Как интересно. И что из этого следует? Речь идет именно об отдельной процедуре локальной обработки данных БД. Вас смущает использование ^W? Так я могу написать ^TMP($Job... Вам сразу станет легче? Считайте это временным массивом. :)
11 янв 07, 16:19    [3628300]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31621
Sergei Obrastsov
Изопропил
Ptn

Почему РУСБД-ники сразу из этого делают вывод что мупсерам нужно будет де исправлять основную программу - именно её и только её.

РУСБД-ники напишут запрос - мупсеры напишут процедуру с локальным индексом - и фсё !!!


Вот почему
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=79#3614088

Как интересно. И что из этого следует? Речь идет именно об отдельной процедуре локальной обработки данных БД. Вас смущает использование ^W? Так я могу написать ^TMP($Job... Вам сразу станет легче? Считайте это временным массивом. :)

Меня смущает не ситнаксис(спасибо всем, освоил), а то что при лёгком изменениеи порядка сортировки приходится достаточно серьёзно модифицировать код.
11 янв 07, 16:44    [3628508]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
Sergei Obrastsov
Изопропил
Ptn

Почему РУСБД-ники сразу из этого делают вывод что мупсерам нужно будет де исправлять основную программу - именно её и только её.

РУСБД-ники напишут запрос - мупсеры напишут процедуру с локальным индексом - и фсё !!!


Вот почему
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=79#3614088

Как интересно. И что из этого следует? Речь идет именно об отдельной процедуре локальной обработки данных БД. Вас смущает использование ^W? Так я могу написать ^TMP($Job... Вам сразу станет легче? Считайте это временным массивом. :)

Меня смущает не ситнаксис(спасибо всем, освоил), а то что при лёгком изменениеи порядка сортировки приходится достаточно серьёзно модифицировать код.


А меня смущает что мумпсерам запрещают пользоваться SQL. И шо ?

А зачем вам тогда М - говорять запрещающие. Агга !!! - нифига вы всё таки без SQL не можете добавляют тут же.

PS: Иех :) "запретить" что ли пользоваться PL/SQL в ответ ? :)
11 янв 07, 17:09    [3628674]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 81 82 83 84 85 [86] 87 88 89 90 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить