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

Откуда: Москва
Сообщений: 33194
Блог
За выходные я дочитал до конца руководство администратора на русском языке (правда, по Cache версии 4) и сейчас уже добиваю руководство программиста (а вот оно по версии 5). Делюсь новыми впечатлениями, сравнивая все дела с MS SQL Server.

1. Про транзакции. В Cache тоже имеется журнал транзакций, но один на весь сервер (и на все базы данных). Схема закрепления транзакций такая же трехступенчатая, как в MS SQL. НО!!! В настройках базы данных и отдельных глобалей можно указать, что журнализируется не все операции. Тогда через журнал транзакций будут проходить ТОЛЬКО те операции, которые явно объявлены как транзакции. Для меня эти вольности не понятны.

2. Техника создания объектов. При создании глобали (аналог таблицы в MS SQL) можно указать кучу всякой настроечной информации, включая номера блоков, с которого она размещается в БД и номера блоков, с которых будет осуществляться поиск новых свободных блоков для включения в глобаль. Мне эти вольности совершенно непонятны. ЗАЧЕМ?! Это все равно, что в MS SQL Server вы при команде CREATE TABLE смогли бы указывать физическое размещение этой таблицы в БД. Ведь можно указать совершенно некорректный номер блока (например, уже занятый другой глобалью). Вообще не понятно, для чего такая "управляемость", почему эти настройки не скрыты. Я убежден, что вопросами распределения блоков между объектами БД должно заниматься ТОЛЬКО ядро.

3. Техника обращения к объектам CSP меня поразила. Если в паре VBScript - IIS нужно сначала создать ADO-шный Connection, потом Command, а уже после через рекордсет получить доступ к каким-либо ЗНАЧЕНИЯМ, хранящимся в БД SQL-сервера, то тут все гораздо проще. При настройке БД просто указывается виртуальный каталог, через который будут "видны" объекты БД. Уже в первой строчке CSP-включения в HTML можно напрямую обращаться к значениям объектов сервера. Никаких отрибутов Connection или аналогичных указывать не нужно - ведь работая с CSP, вы УЖЕ НАХОДИТЕСЬ В КАКОЙ-ТО БАЗЕ. Забавно.

4. Бэкап, который делается без прерывания работы пользователей, работает один-в-один так же, как бэкап MS SQL Server. Он такой же итерационный и многопроходный. Явно этого не сказано, но, как я понял, для обеспечения непротиворечивости используется информация журнала транзакций (иначе и быть не может). Так и остался открытым вопрос - как же это все работает, если в журнал транзакций могут попадать НЕ ВСЕ операции. Видимо, дается на откуп DBA понимание, чего можно и чего нельзя делать. Я понял так, что транзакционным должно быть все. По умолчанию. Если это не так, то сам виноват.

5. Лог шиппинг - есть! Поразительно. Причем, не одного вида, а двух (поблочный и позаписный). А вот подмена вышедшего из строя сервера теневым производится сменой его IP-адреса ( ??? :( ), который обязан быть фиксированным.

6. Соединения. С одного компьютера возможно до 12 одновременных коннектов, которые в лицензионной политике рассматриваются как одно подключение. Приятный нюанс.

7. Распеределенные транзакции. Тоже вроде бы есть. Правда, команд вроде BEGIN DISTRIBUTED TRAN нету (как я понял). Есть лишь механизм обмена серверов информацией, сильно напоминающий репликацию непосредственно обновляемых подписчиков (который в случае с MS использует механизм распределенных транзакций). То есть, указывается, информация из каких глобалей должна попадать автоматом на какие сервера. Пока все красиво и похоже на бочку меда, да? А теперь плюхнем ложку дегтя. Распределенные транзакции НЕ используют MS DTC. Не страшно? Нет? Тогда идем дальше. Распеределенные транзакции НЕ ИМЕЮТ МЕХАНИЗМА ДВУСТУПЕНЧАТОЙ ФИКСАЦИИ. Упали в обморок? Я лежу рядышком с вами. В руководстве администратора на двух листах расписываются все пакости, которые вас могут ожидать по этому поводу. Если репликация непосредственно обновляемых подписчиков даже при наличии двуступенчатой фиксации (в MS) почти не используется из-за резкого снижения надежности совокупности серверов (НЕнадежность каждого из задействованных в распределенных транзакциях серверов умножается), то в случае с Cache надежность просто равна нулю. Непонятно, зачем нужно создавать механизм, пользоваться которым просто нельзя.

8. Репликация. Упорно искал это слово в руководстве администратора, нашел только на одной страничке на одном из скриншотов где-то сбоку в теме, которая к репликации не имеет никакого отношения, куда это слово затесалось как-то случайно. Странно, что такая важная вещь в руководстве администратора скромно опущена. Вопрос остается открытым. Но у меня уже очень сильные подозрения, что на таком уровне как в MS SQL Server она НЕ реализована. По крайней мере, из Distributor, Subscriber и Publisher в Cache как минимум отсутствует концепция Distributor-а. В итоге организацию обмена между серверами вплоть до реализации фукций Distributor-а должен взять на себя DBA. Есть утилиты сохранения глобалей во внешний файл и восстановления их из внешнего файла (которые могут рассматриваться как часть репликации снимком). Но нет понятий "статья" и невозможно задать фильтр - глобаль сохраняется только целиком (если я правильно понял). В итоге, нужно врукопашную сохранять копию глобали в другой глобали (аналог базы данных Distributor-а), самому переписывать из одной глоабли в другую информацию с применением нужных фильтров, выставлять в ней флаги, кому чего отреплицировано, а кому еще нет... Короче реализовать все функции Distributor-а врукопашную. Если я прав (в чем я до конца еще не уверен), то этот момент как-то особо сильно неприятен.

9. Структура базовых классов какая-то чуднАя. Медитировал я, медитировал над понятием "встраиваемый класс", смысел его глубинный так и не понял. Не нашел я аналогий в иных ООП-средах. Сначала я решил, что это аналог абстрактного класса. Но потом выяснилось, что можно объявить поле другого класса как тип "встраиваемый класс". При этом такое поле может получить реальное наполнение, что нехарактерно для абстрактных классов (которые предназначены только для наследования от них). А что, просто класс - он уже не встраиваемый? Разве нельзя создать поле типа "просто класс"? Оказывается, тоже можно. Как я понял, встраиваемый класс предназначен ТОЛЬКО для того, чтобы быть частью другого класса. Хотя для наследования он тоже годится, правда из встраиваемого класса может получиться тоже только встраиваемый. Забавная концепция, нигде ранее подобной не встречал. В то же время (если я правильно понял) в чистом виде абстрактный класс создать невозможно.

10. Отладчик. Есть. С оговоркой, что применяется он к программам, не использующим макроподстановки. Что такое макроподстановка, я пока не знаю, но подозреваю, что это что-то вроде элементов позднего связывания в прочих языках. Одновременно подозреваю, что в Cache они используются несколько чаще и шире. Поэтому эта небольшая оговорка может иметь существенные ограничения для отладки программ (а, может быть, и нет).

11. Garbage Collector какой-то есть. Но не такой, как в C#. Память, занимаемую любым объектом, обязательно нужно освобождать самому. Иначе жди неприятностей.

12. Перехват ошибок. В стиле старого Бейсика, сильно похож на On Error. Ничего общего не имеет с блоками try - except (catch). Странно видеть такой механизм обработки ошибок в ООП-среде.

13. Система безопасности. Примитивная двуступенчатая. Один пользователь может быть только в одной группе (типичный юниксовый подход). Группы в группы включаться не могут. Хотя, есть и интересные вещи. Инструментарий сервера разделен как бы на две части - на инструментарий для разработки программ и на инструментарий для использования готовых программ. Можно определенному пользователю закрыть доступ к инструментарию разработки, и он сможет использовать только разработанные кем-то другим программы. В MS SQL Server подобное невозможно.

Общее впечатление. Очень двойственное. Поражает соседство чересчур сильно проработанных вещей (вроде возможностей множественного наследования) с откровенно примитивными и сильно недоработанными. Буду изучать продукт дальше. Появятся свежие впечатления - поделюсь.
26 май 03, 11:32    [209754]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Я получил ответ по e-mail на предыдущее сообщение в этом топике от одного из сотрудников Интерсистемс. С его разрешения публикую его ответы в форуме, поскольку, как мне кажется, они представляют интерес, а мое мнение, как только начинающего изучать Cache по некоторым вопросам вполне может оказаться ошибочным.

По п.2.
Аналог CREATE TABLE в MS SQL Server - CREATE TABLE!!!
Или с некоторыми оговорками компиляция класса!
И в том, и в другом случае не нужно ничего делать с глобалами!
Они будут сами созданы!
Другое дело, что Вы можете использовать не стандартные механизмы хранения, а свои.
В этом случае, Вы можете придумать свой способ отображения классов на глобалы.
Кстати, чтобы создать глобал, тоже не нужно указывать, где она будет
размещена!
Просто в Терминале наберите Set ^GlobalName(...)=....
И она будет создана!
То о чем Вы писали нужно очень редко для настройки производительности!
Например, если Вы делите БД на разные extent-ы и т.д.

По п.9.
Абстрактный класс есть!
Попробуйте создать класс с помощью Мастера классов!
Есть еще параметр Abstract в Object Inspector.

По п.11.
Нет! Закрывать объекты самим не обязательно! Почитайте:
http://127.0.0.1:1972/csp/docbook/DocBook.UI.Page.cls?KEY=GCRN_objects#GCRN_objects_sysoref

Комментарий Garya.
У меня были основания полагать иначе. Открываю документ "Постреляционная СУБД Cache. Учебный курс. Сиротюк олег. InterSystems Corporation, 2002" на странице 19 и в нижней странице читаем:
Далее сохраняем объект Family в БД и удаляем его из памяти (НЕ ЗАБЫВАЙТЕ УДАЛЯТЬ ОБЪЕКТЫ ИЗ ПАМЯТИ):
USER>write $$DisplayError^%apiOBJ(cl.%Save())
1
USER>do cl.%Close()

Регистр символов приводится в точном соответствии с тем, что указан в документе. Теперь я знаю, что это не правило, а просто признак хорошего тона.
ЗЫ. По ссылке можете не кликать. Это ссылка на собственный компьютер того, у кого установлена Cache.


По п.13.
Ну и с безопасностью все будет переделываться!
Я присылал Вам ссылки на презентации о наших планах!

Комментарий Garya.
Материалы я уже получил, но пока не успел их изучить.
26 май 03, 15:34    [210092]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 Garya
Для удаления класса из памяти сейчас достаточно
переменной присвоить пусто.
PS Я думаю, что лучше это постить в ветку "СУБД CACHE'"
26 май 03, 15:49    [210126]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
В C# переменная удаляется сама при выходе из области видимости. Для этого не нужно вызывать никакие методы и ничего ей присваивать. Это делает GC в отдельном потоке. Переменная будет осовобождена, даже если на нее остались ссылки из переменной, которая также вышла из бласти видимости. (Переменная А может ссылаться на переменную В, а переменная В - на переменную А - в этом случае счетчик ссылок никогда не сможет обнулиться, возникает циклическая ссылка, с которой может справиться только GC C#, анализирующий не только счетчик ссылок, но и выход ссылающихся объектов за пределы области видимости, а также отслеживающего циклические ссылки).
В некоторых других языках переменные освобождаются автоматически по обнулению счетчика ссылок, но это не гарантирует освобождение памяти по нескольким объектам с циклическими ссылками (см.пример выше).
26 май 03, 15:59    [210156]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
В Cache тоже самое - можно и писать лишний код,
но если объект не нужен, то зачем его держать в памяти...
26 май 03, 16:02    [210164]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
nobodyman
Member

Откуда:
Сообщений: 39
Каша

Дурь несусветная, по моему мнению, это должно было умереть лет 15 назад.
Однако - сила инерции.
В основе дряни - многомерный индекс (самый обычный индекс с полями разделителями |- и все) нечто вроде Беркли ДБ , ни записей ни возможности строить дополнительные индексы- МАМПС одно слово.
Т.е. - ключь - значение.
Если Вас это удовлетворяет - флаг в руки , барабан ...
Все остальные навороты - от лукавого, зрить надо в корень.
28 май 03, 12:13    [212594]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Свежие мысли.

1. Насчет аксиоматики, теоретики и практики. Первым ОО-языком была "Simula". Считается, что в формализованном виде принципы ООП изложены в данной работе: D. A. Taylor, Object-Oriented Information Systems: Planning and Implementation, John Wiley & Sons, Inc., New York, 1992. В инете первоисточник мне найти не удалось, только текстовые (а не гипертекстовые) ссылки в списках литературы.

2. Разобрался со встраиваемым классом. Это такая чисто кашевая фича. Что-то вроде объекта, который хранится внутри другого в упакованном виде - сродни размещению сложного объекта в одном BLOB-поле. В оперативной памяти он выглядит привычно. Естественно, при удалении главного объекта удаляется и встроенный. Что-то вроде каскадных операций. Утверждается, что хранение одного объекта непсоредственно внутри другого ускоряет к нему доступ.

3. С relationships все мои невеселые предположения подтвердились. Каскадные операции делаются врукопашную. В связях Parent-Child не может участвовать более одной "таблицы" со стороны "один" (если рассматривать эту структуру как аналог связи один-ко-многим), хотя именно по такой связи работают каскадные операции (даже если вы этого не хотите :) ).

4. С репликацией... Эта вещь меня расстроила сильней всего. Репликации просто нет. Есть простейшие механизмы для обмена информацией между парой баз данных. Есть что-то отдаленно напоминающее репликацию непосредственно обновляемых подписчиков при надежности равной абсолютному нулю. Есть маленькие детальки, из которых вы сами можете (если пожелаете :) ) попытаться собрать авиалайнер - сотворить механизмы репликации врукопашную. Меня заверили, что как раз сейчас в InterSystems идет упорная работа над разработкой механизмов репликации, которые должны появиться в версии Cache 6. Сроки выхода этой версии, к сожалению, не сообщили.

5. Уничтожать самому объекты в памяти стало не нужно начиная с версии 5. Эта фича есть в перечне нововведений 5-й версии. В 4-й это было необходимо.

6. Интересная лично для меня штука - возможность обращаться из собственного кода Cache к DLL. Используя эту возможность, можно сотворить хоть вторую вселенную. Вопрос только времени такого сотворения.

7. Очень меня заинтересовала возможность выполнения динамической подстановки в исполняемый код кусков кода, слепленных в период выполнения. Что особо интересно, эти куски могут быть на разных языках (COS, CBasic и SQL), причем вперемешку (!!!). С помощью этой фичи можно задать такую динамику своему приложению, которая никому и не снилась.

8. С безопасностью уже успел доиграться. Ради эксперимента грохнул бюджет TRM:, включил проверку безопасности и удалил учетную запись _SYSTEM в SQL Manager-е. После чего пришлось сносить Cache и устанавливать заново, потому как достучаться до него никак не мог. В принципе, подобную глупость можно сморозить и на любом другом продукте. Однако, на ошибках учатся.

Пока все.
30 май 03, 19:24    [217184]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Дополнение.

Для обмена данными как между парой серверов Cahe, так и между сервером Cache и чем-либо реляционным (например, MS SQL Server) можно использовать MS DTS. Проверил - работает!

Однако, по большому счету, это все-таки не репликация.
30 май 03, 19:30    [217188]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
И еще несколько свежих впечатлений.

1. Индексы. Кроме привычных в MS SQL Server индексов можно создать индексы, которые внутри себя содержат некоторые данные (какие именно, указывается при их создании). Это что-то вроде кластерного индекса, но их можно создать много. При этом данные дублируются - дополнительно помещаются в страницы индекса. Если ЭТИ данные всегда запрашиваются по условиям выборки индексированного поля, то рекомендуется их положить в сам индекс. Утверждается, что при этом скорость выборки возрастает благодаря тому, что данные выбираются из самого индекса без обращения на страницы данных. Я не берусь выносить оценку данной фиче. Но, ИМХО, скорость обновления данных она должна замедлить (об этом, к сожалению, ничего не сказано). Касательно увеличения скорости выборки - тут тоже бабушка на двое сказала. Помещение данных в страницы самого индекса (в терминах Cache - бллоки) приводит к тому, что на одной странице размещается меньше индексных данных, следовательно может потребоваться больше дисковых операций чтения страниц. Так что у меня по поводу ускорения выборки есть некоторые сомнения.

2. Статистики. В 4-й версии при создании индекса требовалось указывать среднепотолочные значения статистик (вроде того, сколько уникальных значений ожидается по этому индексу). На основе указанных значений оценивалась избирательность индекса и строился план SQL-запроса, а не на основе фактических значений, как в MS SQL Server. В 5-й версии, вроде бы появилось что-то похожее, с помощью чего можно сказать "update statistics".

3. Вычисляемые поля ОО-модели и вычисляемые поля, доступные через SQL - суть разные вещи и настраиваются по-разному. Если они должны появляться и там, и сям, они должны быть дважды настроены. Теоретически можно настроить их по-разному, так что в SQL-запросе они будут показывать одно, а при выборке через ОО-модель - другое. Хорошо это или плохо, оценивать не берусь, просто констатирую факт.

4. Выражения COS (Cache Object Script). Как вы оцениваете математическую запись, сделанную в клетчатой тетрадке ручкой: X = A + BY? Лично я бы оценил ее как X= A + (B*Y). В большинстве известных мне языков есть понятие старшинства операторов. В COS этого понятия нет, все роперации выполняются слева направо по порядку, если явно не завдан их порядок скобками. Следовательно, запись Set X=A+B*Y воспринимается как Set X=(A+B)*Y. В книжке по Cache эта фича представляется как высшее достижение компьютерной мысли. А ИМХО это просто маразм.

5. Отдельного слова заслуживает методология именования переменных, методов и т.д. и т.п. Лично у меня создается впечатление, что их именуют таким образом, чтобы они были как можно менее понятными. Попробуйте догадаться по имени, что возвращает системная переменная $HOROLOG. Никогда не догадаетесь. Текущую дату. Кстати, текущая дата выглядит примерно так:57123.1432. Что, не похоже на дату? Так ведь число до точки - количество лет, прошедших со времен Царя Гороха, а число после точки - количество секунд, прошедших после последней полуночи. А как вы полагаете, что делает системная процедура %GIF? Полагаете, работает с графическими файлами? Не угадали :). Она закачивает глобаль из файла (Global Input from File). Подобные несуразицы на каждом шагу. Мне не понятно, почему нельзя было задавать имена переменным и методам по-человечески. Вот в MS SQL Server я тыкаю пальцем в первую же попавшуюся хранимую процедуру - sp_DeleteMergeConflictRow - и даже не заглядывая в документацию, по одному наименованию уже имею представление о том, что она делает. От кого шифровались-то?

6. Если вы в команде SET A=B поставите два пробела вместо одного между "SET" и "A", то окажетесь сильно неправы. Само существование команды "SET" мне не особенно понятно. В древних версиях бейсика была такая команда "LET", о существовании которой в современных версиях бейсика нынешнее поколение, наверное, и не слышало. Эта команда вымерла как динозавр. И в Бейсике нынче пишут просто A=B вместо того, чтобы писать LET A=B. Появилась там еще бейсиковская команда Set A=B, но это специфическая команда, которая подчеркивает, что вы работаете не с простой переменной, а со ссылкой на объект. В Бейсике команда SET - это команда установки ссылки на объект. В COS SET - это бейсиковский LET и SET вместе взятые.

7. Маска (что-то вроде LIKE) выглядит совершенно нечитабельно. В Access чтобы задать маску выборки файлов с расширением TXT нужно указать "*.TXT". В MS SQL эта эе маска выглядит так: "%.TXT". В COS эта маска выглядит так: .E1"T"1"X"1"T" . Ну как вам? Понятно? Так ведь это еще простенькая маска. А что-нибудь посложнее можно только написать. А вот прочитать вообще никто не сможет.

ЗЫ. Продолжаю углубляться дальше.
2 июн 03, 11:49    [218048]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 Garya
Я так и не понял, что Вы хотите получить от объектов в плане детей,
родителей?
Маску можно и проще задать - ?.E1".txt" мне кажется так понятнее.
Или например проверка IP - ?.3N1".".3N1".".3N1".".3N1"."
Сразу, может и непонятно, но если узнать, что "N" - все числа,
а ".3" - максимальная длина, то все очень даже просто...
И вообще маски можно создавать достаточно сложные, у меня никогда не
возникало проблем с чтением масок.
Вас ведь не смущает, что в паскале надо писать := для присваивания?!
Это просто синтаксис...
2 июн 03, 13:32    [218223]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
> Я так и не понял, что Вы хотите получить от объектов в плане детей,
родителей?

Я тоже не совсем понял, о чем Вы спрашиваете. Подозреваю, что о связях один-ко-многим. Если это так, то постараюсь привести конкретный пример. Есть некоторая таблица фактов движения товара. В этой таблице кроме всех остальных полей есть поля "склад", "кладовщик", "номенклатура". Эти поля завязаны на справочники: "Склады", "Материально-ответственные лица", "Номенклатурный справочник", то есть на три таблицы-справочника. Между таблицой фактов и каждой из таблиц-справочников имеется связь "один-ко многим". Каждая из таблиц-справочников находится на стороне "один", а таблица фактов находится на стороне "многие". В нормальной реляционной среде, поддерживающей каскадные операции, можно эти связи настроить таким образом, что:
1. При удалении склада из таблицы "Склады" автоматически удалятся все факты движения по этому складу из таблицы фактов. Даже если это движение затрагивает множество разных кладовщиков и обширный перечень номенклатуры.
2. При удалении кладовщика из справочника "Материально-ответственные лица" автоматически удалятся все записи из таблицы фактов, связанные с удаляемым кладовщиком. Даже если этот кладовщик работал сразу на нескольких складах и отпускал разную номенклатуру.
3. При удалении из номенклатурного справочника номенклатуры автоматически удалятся все записи из таблицы фактов, связанные с удаляемой номенклатурой. Даже если номенклатура числилась на нескольких складах и работали с ней много разных кладовщиков.

Я понимаю, что далеко не всегда подобные операции должны отрабатывать на автомате. Но иногда должны. В Cache подобную каскадность можно реализовать только вручную. Потому что факты не могут быть дочерними по отношению к складам, кладовщикам или номенклатуре одновременно. А если факты сделать дочерними только по отношению к складам, то каскадное удаление будет работать только при удалении склада, но не будет работать при удалении номенклатуры или кладовщика.
2 июн 03, 14:07    [218299]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Циничный Кот
Member

Откуда: Moscow / St. Petersburg
Сообщений: 6496
2 Garya

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

Мне лично хочется возразить только на один момент:

X = A + BY? Лично я бы оценил ее как X= A + (B*Y). В большинстве известных мне языков есть понятие старшинства операторов. В COS этого понятия нет, все роперации выполняются слева направо по порядку, если явно не завдан их порядок скобками. Следовательно, запись Set X=A+B*Y воспринимается как Set X=(A+B)*Y. В книжке по Cache эта фича представляется как высшее достижение компьютерной мысли. А ИМХО это просто маразм.


ИМХО, это не маразм, а всего лишь непривычное для вас соглашение. Мне приходилось работать довольно долго с языком, в котором порядок выполнения операций определен как left-to-right, и параллельно с языками, которые поддерживают обратный подход (старшинство операций). После некоторого периода общения понимаешь что это в общем-то равноправные подходы, проблемы вызывает лишь необходимость ОДНОВРЕМЕННОГО употребления разных соглашений.


Непривычно - не значит неправильно, не так ли??? :о)
2 июн 03, 17:11    [219019]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Самый натуральный маразм. Надо начинать с того, что понятие старшинства операторов есть в математике.
2 июн 03, 17:28    [219077]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
2 ЦК. Согласен, что непривычно, а не неправильно. Но когда ты решаешь алгебраическое уравнение на листочке бумаги и записываешь формулу параболы в виде y=ax^2 + bx + c, в этот момент ты даже не задумываешься о том, что операция x^2 должна происходить раньше, чем умножение на a, а умножение bx раньше, чем какие-либо сложения. Заметь, речь идет не о языке программирования, а об общепринятых правилах интерпретации и записи математических выражений. Эти правила были выработаны задолго до того, как появились компьютеры.
Мне тоже знакомы иные правила записи выражений. К примеру, польская запись, в которой бинарные операции записываются наподобие функции с аргументами - сначала знак операции, а затем операнды. Но к этому виду записи я отношусь терпимее. Почему?
Потому что что-то непривычное должно предлагаться, по моему глубокому убеждению, только в тех случаях, когда его использование дает какие-то преимущества по сравнению с использованием привычного. В случае с польской записью, например, можно одной операцией объединить сразу множество операндов, а не только два. Кроме того, польская запись очень удобна для машинной интерпретации - поскольку имеет синтаксис очень похожий на вызов функций, с помощью которого легко реализуются принципы полиморфизма.
А какие преимущества дают правила записи в COS? Да никаких! Кроме провышенной вероятности возникновения трудно выявляемых ошибок. Ну и какой смысл был использовать такие правила?
2 июн 03, 17:32    [219091]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Дополнение. В Ассемблере тоже встречаются несколько непривычные для традиционной математики операции. Но это ведь ассемблер. Он ВЫНУЖДЕН их использовать, поскольку его возможности сильно завязаны на специфику процессорных команд. Но использование противоестественных правил в языке высокого уровня, да еще объектно-ориентированном, да еще в постреляционной СУБД, ИМХО, неоправдано.

Кстати, ЦК, что это за язык, в котором ты работал с последовательностью операций left-to-right? Не MUMPS, случаем?
2 июн 03, 17:39    [219114]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Циничный Кот
Member

Откуда: Moscow / St. Petersburg
Сообщений: 6496
2 U-gene

Для тех, кто в танке, повторяю - "непривычно" не значит "неправильно". Откуда старшинство операций возникает "в математике"-то??? Правильно, из определения. А теперь предлагаю задуматься - откуда взялось само определение???... Вот то-то... ;о)


2 Garya

Но когда ты решаешь алгебраическое уравнение на листочке бумаги и записываешь формулу параболы в виде y=ax^2 + bx + c, в этот момент ты даже не задумываешься о том, что операция x^2 должна происходить раньше, чем умножение на a, а умножение bx раньше, чем какие-либо сложения. Заметь, речь идет не о языке программирования, а об общепринятых правилах интерпретации и записи математических выражений.


Ну, началось... Сейчас уйдем в дебри философии. Впрочем, попытаюсь внятно ответить.

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

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

Имхо, это наследие продуктов Микрософт - устойчивый рефлекс "раз так было раньше, то так должно быть и впредь" (пример полезного рефлекса - раздел Exit всегда находится в нижней строке выпадающего меню File). В каких-то случаях следование традициям оправдано, в каких-то - нет. Антипример - раскладка клавиатуры qwerty, имхо, отвратительнаю с точки зрения эргономики - основные латинские буквы разбросаны в неудобных углах.

В-третьих, в измененных "правилах игры" есть глубокий смысл - вы понимаете, что имете дело с другой системой, с другими возможностями, и, возможно, с другой философией. И на С++ можно писать в стиле Бейсик-а, но гораздо полезнее проникнуться мышлением и стилем, которые поддерживает данная среда разработки. Измененные правила вам об этом постоянно напоминают и заставляют задумываться о многих других вещах, которые вы делаете "на автомате". В результате ошибок получается не больше, а меньше, как ни странно... :о)


Хотя аргументацию выбора порядка исчисления мне было бы интересно услышать от разработчиков - почему так а не иначе???... В МС, кстати, нередко отвечают "by design".



Не MUMPS, случаем?

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

Да, кстати... Ес-сно, опечатался раньше - порядок операций не left-to-right, а right-to-left. С конца выражения, короче. Подозреваю, что такой порядок возник из-за того, что парсинг в какой-то мере упрощается. Впрочем, аргументации, почему выбран именно такой порядок - не знаю (или уже забыл ;о), могу как-нить при случае выяснить....


ЗЫ. Приставки пост- и т.п. мне не говорят ничего, пока не становится ясно, что именно за ними стоит.
2 июн 03, 18:32    [219211]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
Я не вижу никаких проблем в использовании записи left-to-right,
тем более, что это ANSI стандарт с 1977... И, соответственно,
нужно для совметимости.
2 июн 03, 18:35    [219214]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Циничный кот

Я бы мог ответить, откуда взялось опреление, но для этого прдется вбивать три странцы текста из курса дискретной математики. Идея в том, что аддитивные и мультипликативные операции не коммутируются и у них разный единичный элемент. В конце концов, если следовать нормальному ходу мысли то скажем 2*3+ 4*5 даст тот же результат что и 5*4+3*2. Здесь выполняется закон "от перемены мест... результат не меняется" (на всякий случай замечу, что этот закон - он тоже не ради прикола). А в вашем случае начинает наблюдаться конкретный МАРАЗМ.

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

Прочитав последнии топики, я начинаю понимать, откуда берутся "постреляционные" БД. Чё уж там про теорию рел. БД говорить, когда мы со сложением и умножением разобраться не можем
2 июн 03, 23:26    [219386]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Добавлю. Я бы мог согласиться, когда аддитвные опреации выполняют преред мультипликативными (в э том случае в скобочки пришлось бы брать умножение-деление). Но чтобы left-to-right и все в кучу? Повторяю, с тчки зрения математики это маразм абсолютный.
2 июн 03, 23:59    [219400]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Полностью согласен с U-gene.

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

А для меня это очевидно. Чем дальше язык от прикладной области, тем он менее удобен просто в силу того, что между реальными объектами, с которыми мы имеем дело в жизни, и их представлением в среде разработки возникает никому не нужный дополнительный барьер. Хочу подчеркнуть, что понятие "объекты" и само ООП возникло как раз из стремления приблизить понятия, с которыми оперирует программист, к понятиям реальной жизни, а не с целью все запутать и отдалить от действительности.

> Имхо, это наследие продуктов Микрософт - устойчивый рефлекс "раз так было раньше, то так должно быть и впредь" (пример полезного рефлекса - раздел Exit всегда находится в нижней строке выпадающего меню File).

Вы считаете, это плохо, что оно ВСЕГДА находится там? Представьте, что у каждой программы оно находилось бы в каком-то своем месте. Вам пришлось бы специально запоминать, где в какой программе оно находится. На это вы потратили бы лишние силы и время. Ну и что в этом хорошего?

> В каких-то случаях следование традициям оправдано, в каких-то - нет.

Совершенно с этим согласен. Я не утверждаю, что категорически во всех случаях должен соблюдаться традиционный подход. Но нарушаться этот подход должен ТОЛЬКО в тех случаях, когда новый подход по сравнению со старым дает какие-то существенные преимущества. Если же он никаких преимуществ не дает (что и имеет место в обсуждаемом случае), то вообще не понятно, ради каких революционных идей произведена попытка сломать привычные представления. Разве что добавить головной боли, как в случае с расположением пункта меню "Exit" в произвольных местах.

> Антипример - раскладка клавиатуры qwerty, имхо, отвратительнаю с точки зрения эргономики - основные латинские буквы разбросаны в неудобных углах.

Согласен. Однако, когда разрабатывался стандарт QWERTY, то он преследовал именно цель сделать клавиатуру как можно менее удобной. В то время компьютеры и периферия имели довольно низкое быстродействие, машинистки колотили по клавишам с такой скоростью, что компьютеры не успевали обрабатывать нажатия клавиш. Чтобы несколько замедлить работу машинисток специально был разработан стандарт QWERTY. Но COS/MUMPS - это другой случай. В математике как раз придумано все так, чтобы было удобнее. Многочлены - это то, с чем математика имеет дело повсеместно. Попробуй записать формулу параболы (частный случай многочлена) по правилам COS:
y = a(x^2) + (bx) + c
И что, нагромождение скобок в формуле делает ее более удобной для восприятия?
Другой пример. Какая запись удобнее для восприятия:
a^2-b^2 = (a+b)(a-b), либо
a^2 - (b^2) = a+b(a-b)
В последнем варианте скобки акцентируют внимание на некоторых операциях, выделяя перед другими. Почему b^2 взято в скобки, а a^2 - нет? Почему a+b НЕ взято в скобки, а (a-b) -взято? Ведь это РАВНОЦЕННЫЕ операции! Подобные правила записи способствуют запутыванию и отвлечению внимания. Теряется видимая симметричность выражений, которые симметричны математически. И какие же плюсы привносят такие правила записи? Назови хоть один. Я ни одного не вижу. Потому мне не понятны причины, по которым разработчик языка ввел подобные правила записи. Точнее, понятны - не особенно хотелось заморачиваться, чтобы сделать так, как положено. Во всех современных языках стараются максимально упростить работу программиста, использующего язык. Зачастую это достигается некоторыми заморочками для тех, кто пишет компилятор/интерпретатор языка. В данном случае поступили наоборот - решили сами не сильно заморачиваться (реализовывая приоритеты операций), предоставив заморачиваться тем, кто будет данный язык использовать. Только выдавать сие за передовое достижение компьютерной мысли не совсем честно. Можно ведь программировать и на Ассемблере. В нем для разработчиков языка воообще минимум заморочек. Только программисты в своей массе предпочитают почему-то использовать языки высокого уровня. Интересно, почему?
3 июн 03, 10:44    [219620]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Циничный Кот
Member

Откуда: Moscow / St. Petersburg
Сообщений: 6496
2 U-gene

2*3+ 4*5 даст тот же результат что и 5*4+3*2

Имхо, не все так просто, как кажется. Еще раз предлагаю задуматься о том, что же такое "нормальный" ход мысли. Для наглядности попробуем следовать вашей же логике и уложиться меньше чем в три страницы: ;о)

- заменим обозначения 2,3,4,5 на a,b,c,d соответственно.
- имеем:

a*b+c*d ~ d*c+b*a

Теперь задумаемся, для всех ли объектов a,b,c,d верно это утверждение???... Не надо быть семи пядей во лбу, чтобы понять - не для всех. Например, для матриц (скажем, размерности 2x2) вот это правило:

a*b ~ b*a

не выполняется. Пример:

a=(1,6;5,2)
b=(3,1;2;5)

a*b=(7,31;19,15)
b*a=(8,20;27,22)


Вопрос: а что же теперь делать с "нормальным ходом мысли"-то, а??? :о)))


2 Garya

А для меня это очевидно.

А для меня - нет. Для меня очевидно, что оба подхода сами по себе равноправны. Другой вопрос, что при одновременном использовании разных нотаций возникает путаница. И если так и происходит в жизни - пользователю (а не разработчику) приходится одновременно оперировать разными нотациями - тогда вопрос к авторам - а почему так???... Вот это неудобно, хотя и не смертельно. Представьте себе, что если бы в жизни вы использовали "нормальную" методику left-to-right. Тогда бы с не меньшим рвением критиковали подход "старшинства" операций - мол, с какого это боку одни операции имеют приоритет надо другими??? ;о)


Вы считаете, это плохо, что оно ВСЕГДА находится там?

Я такого не говорил. Наоборот, я этот пример привел как пример удачного следования традициям. А раскладку qwerty - как пример неудачного. Что касается скобок - они, вообще говоря, как раз способствуют устранению неоднозначности. Насчет читабельности - она далеко не прямо связана с порядком операций - не ставьте пробелов в длинном арифметическом выражении - и оно читаться будет гораздо хуже аналогичного с другим порядком операций, но "читабельным" образом отформатированное... :о)


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

Это вопрос к авторам системы. :о) Возможно, есть причины, возможно, нет, но называть "нечто" маразмом только потому что это "нечто" устроено не так, как привыкли - не есть правильно.


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

И не всегда это хорошо. Я Америки не открою, сказав, что бесплатного сыра не бывает - выигрывая в простоте и скорости разработки, проигрываете в чем-то другом - аппаратных ресурсах, требованиях к памяти, некоторых ограничениях на гибкость. Иногда это очень удачно получается, иногда приемлимо, иногда терпимо, иногда - категорически нет. Если вы занимаетесь серийной штамповкой - будете использовать стандартные средства и вам их будет хватать выше крыши. Будете заниматься уникальными проектами - никуда не денетесь, придется отказаться от стандартных подходов. Мне лично нравится иметь возможность выбора. А любые упрощения в общем-то так или иначе, но ограничивают пространство для маневра.


ЗЫ. И вообще на "массу" я ориентироваться не люблю - если вдруг "всей массе" придет в голову с обрыва головой вниз прыгнуть - мне что, тоже за ними последовать что ли прикажете???
3 июн 03, 15:54    [220342]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Циничный Кот
Member

Откуда: Moscow / St. Petersburg
Сообщений: 6496
ЗЫЗЫ. Ну и матрицы я конечно же перемножил неправильно. Впрочем, суть дела от этого не меняется.
3 июн 03, 15:56    [220345]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
AI
Member

Откуда: Москва
Сообщений: 2817
2 ЦК

Ваш пример с матрицами неудачный. Потому что с числами компьютеры работают напрямую, а матрицы - всего лишь наборы чисел, для которых заданы определенные правила. И для чисел имеется коммутативная алгебра, для матриц - нет. Кстати, для матриц есть и коммутативная арифметика - M1+M2=M2+M1.

Далее a*b+c*d = d*c+b*d в любой записи, но сами эти наборы опять-таки составные. А при a*b=b*a хочется увидеть b*a+c*d=a*b+d*c и т.д.

Мне кажется, что авторы такого бесприоритетного подхода взяли за основу обычный микрокалькулятор и решили, что в этом есть высший смысл. В результате, действительно, получился антиматематический маразм.
3 июн 03, 17:13    [220516]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Циничный Кот
Member

Откуда: Moscow / St. Petersburg
Сообщений: 6496
2 AI

Ваш пример с матрицами неудачный.

Это смотря с какой стороны на него смотреть. Напомню, что постулировалось существование некоего универсального "нормального" мышления и иллюстрировалось это примером 2*3=3*2. Я не вижу причин, мешающих мне ввести вместо цифр буквенные обозначения, ведь для "нормального" мышления не должно быть разницы, иначе же какое оно универсальное???... А если оно не универсальное, зачем кричать, что везед должно быть так??? Ну и на простом примере все упало, сами видели.

Вообще-то говоря, насколько я помню курс алгебры/мат. анализа, сначала вводятся понятия (матриц, вещественных чисел), потом операции над ними, а потом доказываются, подчеркиваю, доказываются те или иные свойства, в т.ч. коммутативность и аддитивность. Это - логичный подход.

А то что выше утверждалось, имхо, и есть "антиматематический", как вы удачно выразились, маразм - взять следствие и выдать его за причину... Лишь потому, что так "всегда делали"
3 июн 03, 17:32    [220549]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Циничный Кот
Всё всё-таки игнорируете главный вопрос: какие преимущества даёт "ненормальный" порядок записи?
Единственное что было - это увеличивается скорость компиляции. Но мне кажется что в наше время временем на компиляцию можно пренебречь.
3 июн 03, 17:56    [220592]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить