Отвечать буду немного не в том порядке, что указано, но иначе будет потерян контекст.

stardg1) Проектируем БД....
У меня появилось ощущение что я попал во времена Win3.1 более убогого и "User-Enemy" интерфейса просто невозможно себе представить...

В общем инструментарий для работы с БД - НУЛЕВОЙ... Правда к чести сказать у них есть другой "Рабочий стол".... расширенный типа.... да там действительно всё красиво, но о его эффективности ничего сказать не могу, т.к. узнал о его существовании уже тогда, когда отказался от ЛИНТЕР в силу других недостатков - и мне уже было не до его тестирования.... Этот рабочий стол был спрятан глубоко в главном меню и узнал о его существовании я чисто случайно, по моему найдя упоминание о нем на данном форуме....

Про глубокую спрятанность в главном меню. В главном меню есть закладка "Расширенные средства администрирования". В ней есть ссылка уже на "Расширенный рабочий стол". Всё.
Достаточно просмотреть меню, как в сознании останется отголосок того, что если обычный рабочий стол не устраивает, то можно использовать расширенный. Ссылки на эту программу есть и из файла readme в корне пакета, и из документации (второй документ в разделе «Графические утилиты администратора»).

Причина, по которой в настоящий момент меню так организовано, в том, что пока не все утилиты имеют новый интерфейс. Например, ещё не полностью модернизирована утилита «администратор узла» - её изменение связано с полной переделкой управления инфраструктурой баз ЛИНТЕР. После того, как она будет закончена, текущий «старый» рабочий стол уйдёт в подменю «устаревшие утилиты администрирования» вместе с группой других утилит.

stardgДля проектирования БД - там есть утилита "Рабочий стол ЛИНТЕР", хосподи - какое это убожество..... например при создании таблицы если ты выбрал тип VARCHAR, и ему автоматически присвоился размер 240, а потом случайно нажал ENTER то всё... это поле Ваше на всю оставшуюся жизнь....

Дело в том, что в ЛИНТЕР нельзя удалять поля, а редактирование поля работает только на уровне переименования и добавления индексов.... как здорово после того как в 10-й раз вводя таблицу из 60 полей на 41-м делать ошибку нажимая ENTER... можно или смирится с тем что у вас в таблице будет лишнее поле (а кому это надо на этапе проектирования БД?) или Дропайте таблицу и начинайте заводить её заново...
Конечно как вариант можно написать скрипт и его накатывать а потом править, но я не из тех людей которые любят двойную работу.....

Во-первых, с сентября 2010 года удаление колонки есть. Хотя, справедливости ради, в демо-версии, выложенной на сайте, его действительно пока ещё нет. В ближайшее время появится.
Кстати, не указано, в какую сторону собирались править размер колонки. В некоторых случаях его можно изменить.

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

В-третьих, рано или поздно скрипт для создания схемы всё равно делается - даже путём выгрузки схемы из свежеспроектированной БД. Т.е. если ошиблись с созданием таблицы, в конце концов можно выгрузить её схему в файл и, затем, подредактировать его. :-)

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

P.P.S. Почему у нас не было DROP COLUMN? Да именно потому, что реально операция редко реально необходима.

stardgИнформации о прохождении запроса НОЛЬ.... точнее там пишется что запрос выполнен за стокато времени и всё... А где план запроса? Где информация о индексах по которым он шел? Наверное создатели СУБД Линтер не думали о том, что кому то эта инфа будет интересна, ведь при заявленной производительности нахрена что то вообще знать о индексах и плане запроса, но о производительности позже....

Эта информация действительно недоступна в настоящее время через интерфейсы администрирования, но эта информация есть. Если обратиться к документации, то документ "Запуск и останов СУБД наплатформе Win32" содержит описание запуска (и информацию для анализа):

/TRACE=DECOMP[=FULL] Задает трассировку исполнения SQL-запросов.

....
Трассировка содержит следующую информацию:
- текст SQL-запроса, переданный на обработку ядру СУБД ЛИНТЕР (после его оптимизации SQL-транслятором);
- какие массивы данных (битвекторы) были задействованы при обработке SQL- запроса. Используемые массивы влияют на время выполнения запроса;
- количество считанных/записанных блоков данных (физических/логических);
- количество считанных/записанных блоков системного журнала.

Соответственно, в этой информации есть и данные об индексах, которые были использованы.

В том же документе можно обнаружить ещё две опции:

/ANALYZE - Оптимизатор СУБД ЛИНТЕР будет анализировать все SQL запросы с точки зрения существования индексов, позволяющих ускорить их обработку. Список рекомендуемых индексов будет выведен на экран консоли ядра и в файл linter.out.

/AUTOINDEX - Разрешает автоматически создавать необходимые индексы для ускорения обработки SQL-запросов. Созданные индексы сохраняются в БД.

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

Да, такое поведение пока существует. Оно связано с желанием уменьшить объём используемой "впустую" памяти. Однако приведённое выше сообщение говорит о том, что и у Вас при подобном обновлении метаданных возникла бы ошибка. И Вы прислали бы скрипт, который включал бы и увеличение "страницы". Логично?

Есть у нас, правда, и худшие ограничения, которые потребуют перегрузки БД в случае роста объёма метаданных. Вот чего хотелось бы избежать. И это ограничение будет снято.

Согласитесь, что у любой СУБД есть ограничения, которые увеличиваются (или снимаются) администратором, а при накате схемы могут сработать…
stardg2) Быстодействие...
Что тут сказать запрос типа SELECT * FROM TABLE из 100 тысяч записей занимает 3 (ТРИ) секунды!!! И это без времени фетча.

Запрос типа типа SELECT COUNT(ID) FROM TABLE из 100 тысяч записей занимает 6 (ШЕСТЬ) секунд!!! Производитель утверждает что это нормально когда впервый раз делаешь запрос, потом всё будет быстрее. У меня быстрее не стало.

Специально создал таблицу на 128К записей. Перегрузил ядро и подал оба запроса. Время отработки или 2 сотых секунды или вообще 0.
Мы утверждаем, что в некоторых случаях (фрагментированная таблица, медленная файловая система, большая на неё нагрузка и т.п.) может быть достаточно длительным время загрузки в кэш, но указанные запросы подкачивают в кэш не больше 100 страниц (по 4к). Т.к он в принципе не может так работать. Исключением может являться:
- использование расширенной защиты данных;
- использование многоверсионной версии с наличием большого количества версий записей;
- неверные настройки БД (или отсутствие таких настроек).

В любом случае имеет смысл разбираться, а не пытаться сразу бросать систему.


Теперь по существу оригинального сообщения в теме:

stardg1) Защита данных от копирования. Чтобы не было такого что можно базу подключить к консоли админа и SQL-запросами, например, >повыдергивать инфу. (С таким сталкивался на IB/FB и MS-SQL Server и на Cache'). Типа на объекте, не зная пароля, в консоль администрирования не войдешь...
Т.е. в идеале соединение с БД должно предоставляться только моему приложением и ничему другому.

Для максимальной устойчивости можно применить шифрование всей БД. Тогда без знания пароля БД вообще нельзя запустить или что-то с ней ещё сделать.

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

stardg3) Работа с BLOB полями. ОБЯЗАТЕЛЬНО сжатие данных на уровне движка!! Хранить надо будет большие rtf-файлы, а они прекрасно жмуться.

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

stardg5) База должна быть в физическом файле на диске, без всяких журналов транзакций и т.д. Желательно разбитие файла БД на тома.

У нас несколько файлов (по 2 файла на таблицу минимум). Журнал отключать можно, но мы это строго не рекомендуем делать. :-) Журнал кольцевой и у него могут быть настроены ограничения на рост. В этом случае транзакция, которая заняла всё "кольцо" журнала, будет откачена.

stardg7) Обязательно установка должна быть очень легкой, без установок СУБД - перезагрузок.

Перезагрузок при установке нет. Более того, можно встроить все компоненты к себе в инсталлятор и использовать свои средства запуска.
Остальные пункты не принципиальны.

Если рассматривать строго по приведённым требованиям, то лучше всего SQLite, за исключением части пунктов, которые приведены в постах выше. Но эта рекомендация совершенно не противоречит предложению попробовать нашу СУБД. :-)

Со своей стороны обещаем всяческую помощь.