Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
LittleCat
Тут не могу согласиться, баг присутствует во всех копиях :-)

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

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

Это безусловно. Прошу прощения, не заметил, что у меня сменился собеседник, и в связи с этим мое "Вы говорите" оказалось некорректным.

LittleCat
Тут я абсолютно согласен. Не определяющий, но и не равный нулю.

Безусловно.

LittleCat
Определяющий критерий - сколько вбухано в рекламу :-)

Нет.
20 окт 06, 12:49    [3287359]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat

Ну началось, сначала отвечали по-человечески, потом пошли ссылки на документацию, дальше видимо будет молчание или оскорбления.

Но тем не менее :

Строка из документации -

Cache' safeguards database updates by using a two-phase technique,
write image journaling, in which updates are first written from memory
to a transitional journal, CACHE.WIJ, and then to the database.

Т.е. имеет место быть дфухфазная запись + гарантированный порядок изменений, такая же как в современных ФС, не более или всё-таки можно из журнала накатить только закомиченные транзакции и откатить незакомиченые ?
20 окт 06, 13:21    [3287663]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Andreww

Т.е. имеет место быть дфухфазная запись + гарантированный порядок изменений, такая же как в современных ФС, не более или всё-таки можно из журнала накатить только закомиченные транзакции и откатить незакомиченые ?

Все можно. Журнал до-записи (wij) служит для обеспечения целостности самих глобалов, на уровне дисковых блоков. Журнал после-записи работает на логическом уровне, в него пишутся транзакции и по нему можно накатить, это если в двух словах.
20 окт 06, 13:33    [3287780]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat

Ага, разобрался, всё на месте, документация действительно бестолковая.
20 окт 06, 15:54    [3289128]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
LittleCat
c127

Ну так ждем уже сколько месяцев. Были предложены вполне реальные задачи с покупкой авиабилетов, сравнили длину кода (а это трудоемкость), оказалось далеко не в пользу М-систем. А после предложения сравнить скорость защитники М-систем вообще разом пропали.

Насчет длины кода
SELECT * FROM tbl AS tbl1 LEFT JOIN tbl AS tbl2 ON tbl1.id_name=tbl2.id_name WHERE tbl1.id_name1='25' and tbl2.id_name1='23'.
и
if ^TABLE(23)=^TABLE(25) s rez=^TABLE(23)
Буковок меньше, да и для понимания проще. (Аргумент на уровне приведенного выше ;-))

Ага, аргумент на уровне, если не читать предысторию, по ссылкам, которые я приводил. А если предысторию все-таки почитать, например в этом топике:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12
то можно найти даже признание вменяемых сторонников М систем, что СКЛ может быть гороаздо компактнее М-овских закорючек. Вот мнение вменяемого М-системщика об СКЛ-е на чуть более сложной задаче, но в которой, в отличие от Вашей, даже сформулировано условие:
"Безусловно все быглядит куда более понятнее и лаконичнее, но мы сравниваем несколько разные вещи. Гораздо интереснее было б взглянуть на сгенерированный низкоруовневый год для этих запросов."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12
Кроме слова "лакончнее" советую обратить внимание на слово "понятнее", я их выделил.



И когда же Вам надоест передергивать по поводу СКЛ-я. Очень понравилось использование алиаса tbl1, который длинее имени таблицы tbl. Молодец, не преденбрегайте ничем, продолжайте в том же духе, это никому не заметно. А еще вместо имени поля id_name нужно выбрать нечто вроде id_name_of_the_customers_partner и потом обвинить в этом СКЛ, ведь разница в длине кода будет еще ощутимее.

Этот же запрос можно записать и так:
SELECT * FROM tbl t, tbl s WHERE t.n=s.n and t.n1='25' and s.n1='23'
Как видим код волшебным образом стал всего на треть длинее Вашей абракадабры:
if ^TABLE(23)=^TABLE(25) s rez=^TABLE(23)
А ведь еще остается вопрос о структуре РБД, проектировать реляционные БД Вы ведь тоже наверняка умеете не лучше, чем писать запросы на СКЛ-е. В правильно спроектированной БД этот запрос может быть короче.
21 окт 06, 02:11    [3291371]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
c127
И когда же Вам надоест передергивать по поводу СКЛ-я. Очень понравилось использование алиаса tbl1

ИМХО Вы размениваетесь на мелочи.
Давайте предложим коллеге показать M-код для запроса
SELECT * FROM tbl AS tbl1 LEFT JOIN tbl AS tbl2 ON tbl1.id_name=tbl2.id_name WHERE tbl1.id_name1>='25' and tbl2.id_name1 in ('23','34','12345')
21 окт 06, 02:25    [3291389]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 LittleCat
Пересказывать документацию, чтобы услышать "выводы ЛП" мне жалко времени, так что если Вам действительно интересно, как устроен журнал в Cache, то не поленитесь прочитать несколько страниц документации....


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

Во-вторых. Если Вам так напряжно односложно (да/нет) ответить на простой вопрос (например, есть ли горячий бекап в каше) - то никто вас и не заставляет участвовать в этом топике. Вы всегда можете покинуть его накуй, оставив на прощанье фразу "курите man'ы, падонки"

В-третьих. Какие-такие "выводы ЛП"? Пока что шло простейшее вопрос-ответное обменивание информацией. То, что в ходе этого обмена всплыла нелицепрятная для Вас (как мумпсового фанатика) информация - ну что ж... а я то тут при чем? Единственный публичный вывод, который я позволил себе сделать на протяжении этого топика - это тот вывод, что ежели наличие изоляции зависит от дисциплинированности сторонних разработчиков, то и изоляции нетути никакой. Из этого, кстате, совершенно спокойно можно сделать вывод, что и транзакций нет никаких (патамушта не бывает транзакций без буквы I).

Скажите, тот факт что в Каше нет транзакций - я могу прочитать в кашовой документации? Или не могу? Если не могу, то...
21 окт 06, 02:38    [3291394]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
andrey_anonymous
c127
И когда же Вам надоест передергивать по поводу СКЛ-я. Очень понравилось использование алиаса tbl1

ИМХО Вы размениваетесь на мелочи.

Не сдержался, уж очень мне нравится как кешисты аргументируют. Недавно заявили, что "Ну тогда не нужен Вам никакой SQL. Берете например GT.M и весь Ваш запрос превращается в один оператор"
https://www.sql.ru/forum/actualthread.aspx?tid=347471&pg=1#3235976
Можно подумать что СКЛ операторов было больше чем один.
То 50000 запросов в секунду будет летать на GT.M на 220%, хотя никто не проверял, теперь эти алиасы.

andrey_anonymous
Давайте предложим коллеге показать M-код для запроса
SELECT * FROM tbl AS tbl1 LEFT JOIN tbl AS tbl2 ON tbl1.id_name=tbl2.id_name WHERE tbl1.id_name1>='25' and tbl2.id_name1 in ('23','34','12345')

Можно и так. Я уже предлагал вопросы по задаче с авиабилетами, там вполне реальные запросы и очень хорошо видно что СКЛ компактнее.
22 окт 06, 07:24    [3292549]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Andreww

Отказоустойчивость : как в CACHE (и в аналогах типа GT.M) устроен журнал, есть ли возможность резервирования журнала для дальнейшего использования ,как можно накатить изменения (есть ли автоматической восстановление после сбоя) , есть ли средства горячего бэкапа, есть ли инкрементальный бэкап.


Automatic Journaling of Transactions

Rolling Back Incomplete Transactions

Backup Integrity and Recoverability
22 окт 06, 20:36    [3293106]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
ЛП
Andreww
Тогда второй вопрос - есть ли транзакции, т.е. группа операций которую можно принять или отменить только совместно ?

И вдогонку третий вопрос - если транзакции есть, то какие уровни изоляции поддерживаются (из списка Read Committed, Repeatable Read, Snapshot и Serializable)?


К сожалению далеко не все :(
22 окт 06, 20:45    [3293114]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
andrey_anonymous
c127
И когда же Вам надоест передергивать по поводу СКЛ-я. Очень понравилось использование алиаса tbl1

ИМХО Вы размениваетесь на мелочи.
Давайте предложим коллеге показать M-код для запроса
SELECT * FROM tbl AS tbl1 LEFT JOIN tbl AS tbl2 ON tbl1.id_name=tbl2.id_name WHERE tbl1.id_name1>='25' and tbl2.id_name1 in ('23','34','12345')



Сравнение декларативного запроса на макро-языке неуместно с процедурным кодом M-языка, я уже об этом говорил в одном из ранних топиков на похожую тему. Если уж сравнивать, так длину какого-нть объектного кода, не принимая ввиду его эффективность.

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

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

Приведенные мной в топике код приводился на чистом М-стандарте, без использования объектных возможностей каше. В этом случае возможно наглядность решения задачи была бы выше, ибо объектный код, имхо более читаем в отличие от порой сложных sql-запросов (я не имею ввиду сложных как в приведенной ранее задаче о билетах)
22 окт 06, 20:59    [3293130]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

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



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

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

Краткий вариант:
S g=$NA(^ALLDOC) F  S g=$Q(@g) Q:g=""  I @g["test W !,g,"=",@g

То же самое в полном синтаксисе:

Set g=$NAME(^ALLDOC) 

For  {
           Set g=$Query(@g) 
           Quit:g=""  
           If @g["test Write !,g,"=",@g
}
22 окт 06, 21:12    [3293151]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Rus000

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

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



без понятности - не будет надёжности. А надёжность зачастую важнее "скорости"

- Это правда, что вы печатаете со скоростью 1500 знаков в минуту?
-Да, но такая ерунда получается...
22 окт 06, 21:40    [3293192]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Rus000
Сравнение декларативного запроса на макро-языке неуместно с процедурным кодом M-языка, я уже об этом говорил в одном из ранних топиков на похожую тему. Если уж сравнивать, так длину какого-нть объектного кода, не принимая ввиду его эффективность.

Не согласен. Сравнивать на "компактность" надо код, писанный человеком - в противном случае сравнение теряет смысл.
Что до "эффективности"...
В случае М-систем эффективность будет чрезвычайно сильно зависеть от квалификации разработчика как программиста.
В случае SQL - разработчик несколько меньше связан с трудами Кнута и может больше внимания уделять предметной области.
Если же говорить об эффективности в абсолютных цифрах - добро пожаловать на www.tpc.org, только М-систем я там что-то не видел :)
22 окт 06, 22:23    [3293230]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

Сравнение декларативного запроса на макро-языке неуместно с процедурным кодом M-языка, я уже об этом говорил в одном из ранних топиков на похожую тему. Если уж сравнивать, так длину какого-нть объектного кода, не принимая ввиду его эффективность.

Наверное, не деклартивного запроса на макро-языке, а деклартивного запроса на декларативном языке БД.
Так сравнивать не уместно в каком смысле? Императивность - признак третьего поколения, а декларативность четвертого? Если для БД удалось создать декларативный, достаточно выразительный, то имеративный - признак устаревших подходов? Или в каком смысле не уместна? Раз назвали деклалативный и императивный, то уже как бы сравнили, как минимум те кто назвал.
Или в том, что М не претендует на то, что он язык БД и тогда он в одном ряду с С, С++, JAVA и сравнивать надо с ними?
Тут вроде были мысли, что М интегрированный, т.е. и язык БД и универсальный.
Тогда как язык БД он претендует на сравнение с другими языками БД, а как универсальный на сравнение с С++, JAVA, C#. Ну или хотя бы для начала с Вижул Басиком.
Вот парни и сравнивают. А что остается? Согласитесь, что сегодня такие языки как М могут вызывать недоумение. Все-таки они из дореляционной эпохи. Своего рода средневековья в ИТ. Как тут не посравнивать?
22 окт 06, 23:59    [3293288]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
2 Rus000
ЛП
Andreww
Тогда второй вопрос - есть ли транзакции, т.е. группа операций которую можно принять или отменить только совместно ?

И вдогонку третий вопрос - если транзакции есть, то какие уровни изоляции поддерживаются (из списка Read Committed, Repeatable Read, Snapshot и Serializable)?


К сожалению далеко не все :(

А не могли бы Вы немного пояснить...
Вот LittleCat говорит, что "... в Cache все гораздо хуже, и без тех же LOCK пользоваться им (механизмом транзакций - прим. моё) (ИМХО конечно) нельзя (хотя он и берет на себя часть черновой работы), поскольку изменения, сделанные внутри тразакции одного процесса становятся "видны" всем другим еще до выполнения TCOMMIT или TROLLBACK...", и что дескать нужно дисциплинироватьт разработчиков, бить по руках ползающим в глобалы, изобретать библиотеки/инструменты, и т.д., и т.п.
А по Вашей ссылке следует, что типа Read Commited есть, и дополнительных телодвижений не требует.
Кому верить?

З.Ы. Вот этот кусок из приведенной ссылки:
Query operations using the SELECT DISTINCT or GROUP BY clauses, or invoking aggregate functions are unaffected by the ISOLATION MODE option. Aggregate functions always return the current state of all changes, including changes not yet committed.

- это что, действительно так? Или это меня глючит с переводом с английского на русский матерный?
23 окт 06, 05:23    [3293410]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Rus000

Да вроде как всё есть (журналы в смысле), только один вопрос остался непонятным :

"One command marks the beginning of the transaction; after a sequence of possibly many commands, another command marks the end of the transaction."

Если не "начать" транзакцию будет ошибка ? Или транзакция начинается неявно (зачем тогда оператор "начала" нужен, для точки сохранения)? Или каждый DML оператор будет в транзакцию завёрнут ?

Просто пугают куски из догументации типа :

%INTRANS Detects whether a transaction is currently in progress:

* <0 means in a transaction, but journaling disabled.
* 0 means not in a transaction.
* >0 means` in a transaction.

Как это "0 - НЕ В ТРАНЗАКЦИИ" ! А где ?! Нафигаж тогда журналы городить если могут быть операторы которые "not in a transaction" ? И как может быть <0 в транзакции, но без журнала, кто и как rollback будет делать ?
23 окт 06, 10:24    [3293923]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
ЛП

Кому верить?

З.Ы. Вот этот кусок из приведенной ссылки:
Query operations using the SELECT DISTINCT or GROUP BY clauses, or invoking aggregate functions are unaffected by the ISOLATION MODE option. Aggregate functions always return the current state of all changes, including changes not yet committed.

- это что, действительно так? Или это меня глючит с переводом с английского на русский матерный?

Мне верьте "Мы, русские, друг друга не обманываем" (с) Брат-2. А если серьезно, то приведенный фрагмент документации описывает надстройку над чистым М (Cache ObjectScript, как ИС его называет) - Cache SQL, и там действительно это реализовано.
А в чистом Cache ObjectScript только Read Uncommited, как Вы выражаетесь :-)
23 окт 06, 11:33    [3294424]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Andreww
Да вроде как всё есть (журналы в смысле), только один вопрос остался непонятным :

"One command marks the beginning of the transaction; after a sequence of possibly many commands, another command marks the end of the transaction."

Если не "начать" транзакцию будет ошибка ? Или транзакция начинается неявно (зачем тогда оператор "начала" нужен, для точки сохранения)? Или каждый DML оператор будет в транзакцию завёрнут ?

Просто пугают куски из догументации типа :

%INTRANS Detects whether a transaction is currently in progress:

* <0 means in a transaction, but journaling disabled.
* 0 means not in a transaction.
* >0 means` in a transaction.

Как это "0 - НЕ В ТРАНЗАКЦИИ" ! А где ?! Нафигаж тогда журналы городить если могут быть операторы которые "not in a transaction" ? И как может быть <0 в транзакции, но без журнала, кто и как rollback будет делать ?


M-язык н)а котором функционирует ядро всех М-систем представляет собой комбинацию классического процедурного языка, и функций обработки данных (DML) хранимых логически в глобалах а физически в B*-деревьях.

Фактически М-система представаляет собой 2 в одном флаконе - СУБД с функциями помещения, извлечения и удаления данных из/в глобалов и сервер приложений, исполняющий бизнес-логику на базе M-языка. При этом эти database- и app- сервер выделены лишь логически, концептуально - они суть одно и то же - либо database-сервер с возможностью написание ХП (хотя здесь нет такого термина, просто приведена аналогия), либо app-сервер с возможность непосредственной работы с данными минуя посредников.

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

Отвечая на Ваш вопрос можно сказать что в программах (бизнес логика) существуют куски кода ВНЕ транзакции, если того хочет программист, и куски кода В ТРАНЗАКЦИИ если необходимо обеспечить целостность при работе с данными. Замечу, что TSTART-TCOMMIT делаются при программировании логики на чистом M, при программировании в объектной архитектуре каше этого как правило не требуется, т.к. любой Save объекта включает в себя транзакционные скобки.

Блокировка и транзакционные скобки вообще говоря не одно и тоже.

* <0 means in a transaction, but journaling disabled. для меня то же странно, но видимо означает, что транзакционные скобки в программе стоят, но системный журнал отключен (такое допустимо). Соответсвенно роллбак в этом случае отработать не должен, ибо откат происходит именно по журналу. Отсюда следствие - нехрен выключать журналирование.
23 окт 06, 12:33    [3294992]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
OS/360
[quot Rus000]
без понятности - не будет надёжности. А надёжность зачастую важнее "скорости"


имхо спорная мысль про первое, про второе соглашусь хотя ... тоже фифти-фифти :))
23 окт 06, 12:38    [3295050]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Rus000
имхо спорная мысль про первое

Она "спорная в отдельных случаях" и "верная почти всегда".

Rus000
про второе соглашусь хотя ... тоже фифти-фифти :))

Тоже не фифти-фифти. Сценка еще из книги семидесятых годов:

Программист1: "Моя программа вдвое меньше твоей и требует в четыре раза меньше памяти!"
Программист2: "Да. Но моя программа - работает".
23 окт 06, 12:45    [3295115]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
andrey_anonymous

Не согласен. Сравнивать на "компактность" надо код, писанный человеком - в противном случае сравнение теряет смысл.


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

andrey_anonymous

Что до "эффективности"...
В случае М-систем эффективность будет чрезвычайно сильно зависеть от квалификации разработчика как программиста.
В случае SQL - разработчик несколько меньше связан с трудами Кнута и может больше внимания уделять предметной области.


эффективность решения всегда зависит от квалификации разработчиков, начиная прямо с архитектуры решения, так что не знаю может ли неквалифицированный SQL-программист сделать более качественное решение нежели квалифицированный М-программер. Диалектический спор, однако, предлгаю далее не флеймить, если Вы не против.
23 окт 06, 13:00    [3295275]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
vadiminfo

Наверное, не деклартивного запроса на макро-языке, а деклартивного запроса на декларативном языке БД.


масло масляное, ну да ладно сути это не меняет :)

vadiminfo

Так сравнивать не уместно в каком смысле? Императивность - признак третьего поколения, а декларативность четвертого?

однако третье поколение не ушло со сцены а только лишь приятно дополняет "четвертое", не так ли? Хотя бы написание клиентской части ИС вынуждает Вас использовать именно третье якобы устаревшее поколение

vadiminfo

Или в том, что М не претендует на то, что он язык БД и тогда он в одном ряду с С, С++, JAVA и сравнивать надо с ними?
Тут вроде были мысли, что М интегрированный, т.е. и язык БД и универсальный.
Тогда как язык БД он претендует на сравнение с другими языками БД, а как универсальный на сравнение с С++, JAVA, C#. Ну или хотя бы для начала с Вижул Басиком.


см. пост выше

vadiminfo

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


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

с другой стороны мне трудно здесь быть объективным - в свое время (12 назад) я просто влюбился в mumps, а первая любовь сами знаете ... :))
23 окт 06, 13:14    [3295402]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 RUS000

"...существуют куски кода ВНЕ транзакции, если того хочет программист.."

Т.е. они пишут в обход журнала транзакций ... или ... ?


"я принимал на работу минимум 6-х новых работников которые влет осваивали язык и сам М-подход и начинали работать "на выход" уже после двух-трех недель ознакомления"

Хм... Не страшно ? Один оператор DML "ВНЕ ТРАНЗАКЦИИ" такого новичка (из-за неопытности\невнимательности\спешки и т.п.), и с целостностью БД можно попрощаться, внешне всё будет пристойно и гладко, до первого restore, когда из журнала накатится шняга и без анализа исходного кода невозможно будет понять почему накатилась такая чушь :( Можно конечно будет всех 6-х уволить\избить\уничтожить - шутка конечно, но когда стоимость базы измеряется сотнями тысяч денежных единиц шутки заканчиваются, вместо базы будет МУСОР.
23 окт 06, 13:43    [3295689]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Andreww
2 RUS000

"...существуют куски кода ВНЕ транзакции, если того хочет программист.."

Т.е. они пишут в обход журнала транзакций ... или ... ?


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

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

тут дело все в том что мы рассматриваем M на уровене абстракции ниже чем sql-предложение, в котором де факто и зашита вся транзакционная обработка.
Поэтому если мы используем в М-языке доступ к данным
а) через объектный и SQL-интерфейсы
б) через специально написанные на M (возможно унифицированные) процедуры UPDATE,DELETE, INSERT
то за целостность и согласованность можно не беспокоиться.

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

Andreww

Хм... Не страшно ? Один оператор DML "ВНЕ ТРАНЗАКЦИИ" такого новичка (из-за неопытности\невнимательности\спешки и т.п.), и с целостностью БД можно попрощаться


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