1. С информационной точки зрения есть только две сущности: исполняемый код и данные.
2. Место хранения исполняемого кода это, наверное, библиотека программ, а место хранения данных – база данных.
3. БД как совокупность последовательных файлов рассматривать не будем.
4. С точки зрения ОС, БД это файл с прямым доступом к сегментам диска.
5. С логической точки зрения (или с точки зрения ядра СУБД) БД это совокупность блоков со ссылками друг на друга.
6. Есть внешнее представление данных и внутреннее.
7. Внутреннее – это то, как данные запихиваются в блоки и как из них извлекаются.
8. Внешнее – это то, как данные видит пользователь: дерево, таблица, объект, или что-то еще.
9. Переводом данных из внешнего представления во внутреннее и наоборот занимается ядро СУБД.
10. Вопросы обеспечения сохранности данных и их логической целостности не рассматриваем, т.к. если они не решены, то это не СУБД, а какая-то фигня.
11. Внутреннее представление данных у всех СУБД принципиально не отличается.
12. Следовательно, различие СУБД лежит во внешнем представлении данных и предоставляемом сервисе по работе с данными:
- доступ к данным как к деревьям с набором функций обработки деревьев (М-системы);
- доступ к данным как к таблицам с языком SQL (реляционные БД);
- доступ к данным как к объектам (постреляционные БД).
13. Термин «постреляционные» очевидно проистекает из того, что поиск объектов в постреляционных базах производится не объектыми методами, а либо через SQL, либо с помощью прямого доступа.
14. Реляционные БД и SQL это логическое продолжение БД типа набора последовательных файлов и хорошо укладывается в прямоугольное представление о мире.
15. Ни один из вышеперечисленных способов представления данных в чистом виде не позволяет построить оптимальную информационную модель достаточно большой информационной системы.
16. Критерий оптимальности: максимальная скорость реакции при минимальных требованиях к ресурсам и максимальная информационная отдача при минимальном количестве действий пользователя + минимальные усилия по сопровождению и развитию системы.
17. Прослойки типа SQL и хранимых объектов может быть и облегчают жизнь разработчику, но для достижения главной цели (оптимальности) вредны.
18. М-СУБД позволяют, помимо прочего, рассматривать хранимые данные и как деревья, и как многомерные ассоциативные массивы. На базе такого представления не составляет проблем приложить некоторые усилия для создания инструментария обеспечивающего общение с данными эквивалентное SQL и работе с объектами.
19. М-СУБД больше подходит термин не СУБД, а Хранилище Данных (Data Store), позволяющее реализовывать нужные модели СУБД и их комбинации.
20. Этот термин (ХД) явно используется производителями GT.M – М-системы, бесплатной под Linux.
21. Вывод: выбор GT.M для разработки серьезных информационных систем – единственно верное решение.

Ссылка на сайт:
http://www.sanchez-gtm.com
где вы можете взять эту замечательную систему и информацию о ней.
Однако, под MS Windows вы ее не найдете, так как всем давно известно, что MS Windows относится к разряду ненадежных систем и в качестве серверной ОС к использованию не рекомендуется.
Корпорация Санчез http://www.sanchez.com производит свои системы для банков и финансовых организаций на основе GT.M. Что касается Востока, пока добрались до Польши.

На сайте http://www.systema2003.kiev.ua можно посмотреть на работающую систему использующую GT.M для хранения данных. Заходить на сайт лучше бесплатным браузером Mozilla (скачать для любой платформы с http://www.mozilla.org) или NN. Как выяснилось, IE очень коряво работает с JS что доставляет массу неудобств.

У пунктов 16 и 17 конфликта нет. Речь идет о больших информационных системах и их постоянном сопровождении и развитии, как того требует жизнь и всякого рода гос. думы посредством своего законотворчества. Общеизвестно, что у реляционных баз есть порог количества таблиц и количества записей в этих таблицах, после которого сложность сопровождения структуры БД и время обработки информации начинают возрастать экспоненциально. Для оптимального решения такая зависимость должна быть либо линейной, либо нулевой, что и наблюдается в случае использования GT.M.

В: Почему мы не рекомендуем использовать Internet Explorer ?
О: Потому, что IE не достаточно корректно отображает HTML код и работает с JavaScript. Например, поля ввода он делает на 2 - 3 символа шире, чем это указано в параметре SIZE, а при помещении фокуса в заполненное поле он размещает курсор в начале текста, а не в конце, окна открывает где сам хочет игнорируя параметры screenX и screenY и т.п.

Т.е. ИЭ конечно работает с JS, но не так, как я вправе от него ожидать согласно документации.

Использовать ИЭ конечно не возбраняется, но работать будет менее удобно, чем в более корректном браузере.

Назовите мне хотя бы несколько крупных буржуйских банков или заводов, использующих в качестве серверной платформы MS Win. И еще вопрос - Какую ОС использует MS для серверов внутри своей организации ?

Об экспоненциальности и источниках общеизвестности.
---------------------------------------------------------

Источники есть, но давно читал, а искать лень.
Думаю, достаточно будет элементарной логики.

Возьмем гвоздь реляционности – оператор SELECT.
И возьмем его с JOINами, ибо селект без джойнов это работа с последовательными файлами, а не с БД (неважно, явные джойны или нет).
Для большей наглядности, переходящей в очевидность, возьмем в качестве примера пороговый случай.

Итак, имеем РСУБД где:
N – количество таблиц,
Zt – количество записей в таблице t.
Селект с джойном всех таблиц возвращает количество записей K= Z1*Z2*…*Zt*…ZN и выполняется за время S.
Средняя скорость формирования одной записи V=S/K.
Добавим еще одну таблицу со ста записями.
Количество возвращаемых записей увеличится в 100 раз.
Конечно, время выполнения селекта увеличится менее чем в 100 раз (надеюсь), но и не на 100*V, а значительно больше.
Т.е. имеем факт нелинейной зависимости производительности системы от количества записей и количества таблиц в БД.
Теперь добавим 100 записей в 1-ю таблицу – эффект тот же.

Теперь о пороговых величинах и о зависимости между относительными и абсолютными величинами.

Если вам предложить 1 доллар или 1 шанс из 10 получить 10 долларов – вы скорее предпочтете шанс, но если вам предложить 1000000 долларов или 1 шанс из 10 получить 10000000 долларов, вы наверняка откажетесь от шанса и предпочтете верный миллион.
Где-то между этими случаями лежит порог, после которого ваше мнение о том, что 1/10 это всегда 1/10 изменилось. Аналогично, на компьютере определенной мощности время выборки в 1000000 и в 10000000 будет соотноститься меньше, чем 1/10, а 1000000000 и 10000000000 больше. Установить пороговое значение можете экспериментальным путем – где-то оно есть (разное для разных баз и компьютеров, но есть).

Об ИЕ
------

Как-то вы незаметно с разговора о JS на CSS перешли.
Все-таки с точки зрения пользователей, которые в браузере не только смотрят картинки, а вводят немаленькое количество информации, периодически обращаясь за помощью к справочникам, открытие новых окон в неправильных местах создает массу неудобств, т.к. нужно отвлекаться от основной работы и заниматься ручным перетягиванием окон в нужные места.
И все-таки, отрабатывает ИЕ параметры screenX и screenY при открытии окон или нет ?
Я вижу - что нет. Или и здесь нужно указать источники очевидности.
Еще момент. Очевидно, что приложение с веб-интерфейсом должно иметь кроссплатформенный характер.
На скольких платформах работает Мозилла и на скольких ИЕ ? То-то же …
Опять же очевидно, что ориентироваться на ИЕ нельзя, т.к. кроме МС Вин его нигде нет.
Плохо конечно, что в Мозилле шрифты не совпадают, но это же мелочь по сравнению с неудобствами ИЕ. Кроме того, в Мозилле размер шрифта переключается моментално клавишами Ctrl+ и Ctrl- чего в ИЕ нет.

О течениях
-----------

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

Об остальном – позже.
(Рабочий день кончается.)

>другая фишка, что 99% тех кто на этом форуме, находятся в том диапазоне что >лучше ляб баксов тыщща баксов наверняка(использование эскуэль рсубд) чем >лям баксов может быть(используя новый, неопробавонный продукт)

Так что, если не пробовал - может пора попробовать. А то " ... так и жизнь пройдет - без пива, бабок и телок ..."

А вообще-то, если кто хочет всерьез попробовать GT.M - пишите. Попробую помочь.

и из-под Дэльфей под Виндовс и из-под Кайликс под Линукс.

>А из-под явы явской?

Если через JDBC устраивает, - легко.


>вот ты мил человек своими деньгами и попробуй. вложи в проект свои деньги. >выгорит - заработаешь. а не выгорит. ну что же попробовал ... :-).

Уже лет 20 пробую и все почему-то выгорает.

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

Похоже, что так. Я, собственно, никакого риска и не предлагаю. Деньги тут вкладывать особо некуда. Время, конечно, нужно, но не так уж и много.