В нескольких последних ответах заметно повышенное внимание к нескольким особым аспектам разработки в Лотусе, что вызывает желание заменить ранее намеченный пунктир тонкой, но сплошной линией
Так, сказать, обозреть с высоты воробьиного полета.
Понравилась реплика госпожи Нефедовой о mySQL... Разрешите напомнить, что есть "реляционность": это всего лишь wrapper, оболочка, предоставляющая доступ к данным в терминах теории множеств, с использованием элегантных математически строгих операций этой теории. Поэтому те, кто привык к реляциям, на деле привык именно к упомянутой абстрактной модели данных. Как ни удивительно (
), существуют и другие модели данных! В частности, ISAM, индексно-последовательный доступ к данным, родившийся во времена оно, когда компьютеры были большими. Если приподнять реляционное одеяло, то мы увидим голые ISAM-файлы.
К чему это? Да просто до мощных, промышленных RDB, все базы данных программировались, как ИСАМы. А это совсем другая методология и другая абстрактная модель данных! И другой набор операций над данными. И, нужно сказать, ИСАМ требует больше труда и изобретательности, хотя, в принципе, его возможности шире. Нужно опредилить состав записей, наборы ключей, по которым они будут индексированы, т.е. без четкого уяснения семантических и формальных (синтаксических) взаимосвязей результат определенно будет плачевным. В отличие от реляций, где простая (может быть автоматизирована, спасибо мат. модели) процедура нормализации практически гарантирует качество реализации БД. Все понятно: низкоуровневое средство (ИСАМ) по определению мощнее, но требует для достижения мощного результата больше труда и мастерства, чем качественно реализованная высокоуровневая оболочка. (Другой пример: ассемблер по сравнению с языками высокого уровня). И вот: тот, кому приходилось писать базы данных на обычных языках в файловой системе с помощью разных, поддерживаемых на уровне ОС методов доступа к файлам (в т.ч. ИСАМ), тот уже вообще ни на что никогда не жалуется!
Уважаемые, Лотус реализует ISAM-идеологию доступа к данным! Виды с категориями, отсортированные по первым нескольким столбцам, getDocumentByKey... Еще вопросы будут?
Второе. В документации к современным Лотусам этого нет, но в старых релизах очень хорошо прописывалась идеология работы пользователя. Это сейчас Лотус начал постепенно сползать неизвестно куда, но и теперь его насквозь пронизывает идеология "Офиса". То есть предполагается, что пользователь так же свободно создает свои базы, формы, виды, как и работает с электронными таблицами! И совершенно естественно, что для рядового пользователя не предусмотрены мощные хитромудрые средства, которыми нашпигованы т.н. профессиональные движки СУБД. Наверное это обстоятельство является определяющим по отношению к функционалу, доступному разработчику, и хорошо характеризует модель БД, принятую в Лотусе. Наряду с этим, Лотус реализовал системные сервисы, которые можно-таки считать образцом для подражания иных СУБД. Например, "родные" RTF поля выглядят чужеродными и неорганичными в реляционках. А чего вы хотели? Они не укладываются в мат. модель! Другой пример -- Лотус первая в мире СУБД, реализовавшая технологию клиент-сервер. Ну и так далее.
Словом, модель данных Лотуса простая, но низкоуровневая, а интерфейс пользователя и разработчика рассчитан на RAD режим эксплуатации, в стиле настольной автоматизации "своими руками", поэтому сравнительно беден и не удовлетворяет гуру, привыкшего месяцами "копаться" в навороченных "бэкэндах", совершая ему одному заметное шаманство. Как говорилось: "приходит пользователь и стоит над душой, пока я ему это не сделаю..." Но, Лотус в то же время работает на движке, который реализовывал и реализует потрясающие по силе и новаторству технологии, которые служат образцом в индустрии. Вот такая оценка ситуации.
