Обсуждение развития MSEide + MSEgui

[debi12345]

Готовый проект-пример :

http://brefi.narod.ru/print_testcase.zip

Иллюстрирует :

- SQLQuery в локальном режиме

- добавление/сохранение фотографий черех BLOB-поля

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

- PopupMenu со значками действий

- распечатка отчета :
= по всем данным
= по текущей записи, распечатывая также и фотографию (цветной режим )

- меню настройки печати

- форматирование отображения/печати данных с плавающей точкой

И все это абсолютно прозрачно между Linux & Win-32.

[debi12345]

Добавлено :
- компонент TSQLScript :
= группа SQL-команд, выполняемая последовательно
= принимает параметры запросов (поэтому SQL-команды могут быть параметрическими )
= есть интерфейс к T{PQ/IB/SQlite3/MySQL(x)}Connection, что позволяет выполнять эти команды автоматически при коннекте во время дизайна ( неоценимо в случае использования виртуальных таблиц SQlite3 - слияния нескольких файлов-БД в одну посредством команд "ATTACH DATABASE.." )

[debi12345]

В SVN добавлено несколько примеров. Некоторые из них - весьма сложные.

[Alexander]

Спасибо !

А я всё подбираюсь к органайзеру и глядя на всякие бд штучки
задумываюсь о формате файлов. Пока остановился на текстовых с
табуляторами-разделителями. Даст ли что нибудь принципиально
существенное применение бд - не знаю.
Никогда не работал с бд (совсем). Предполагаю бОльшие габариты и
меньшую надёжность, сложность переноса и настройки, а вот плюсы...

Кстати про Postgresql случайно прочитал в конференции, может будет
кому (когда) полезно:

# service postgresql start
FATAL: incorrect checksum in control file

Как исправить?
2.6.20-1.2925.fc6 #1 SMP x86_64

После чего это началось? Вы подсунули постгресу файлы баз от другой
версии? (например от 32-х битной)

Точно!
Идти в 32-х битное окружение и конвертировать... во что? Да?

Перед миграцией нужно всегда делать дамп при помощи pg_dump или
pg_dumpall, а потом заливать его в новую версию при помощи psql.
http://www.postgresql.org/docs/8.1/stat ... ading.html

Вам нужно вернуть старую 32-х битную версию, сделать в ней дамп,
поставить новую 64-битную версию, загрузить в нее дамп.

[debi12345]

Никогда не работал с бд (совсем). Предполагаю бОльшие габариты и
меньшую надёжность, сложность переноса и настройки, а вот плюсы...
=========
Не связывайтесь с псевдоформатами типа "comma-separated". И даже с memdataset. У компонента TMseSQLQuery есть оффлайновый (вообще без выделенной БД ) режим - когда он хранит данные в файле собственного формата (вкл. BLOB-поля). Огромный плюс - доступ ко всему мощному сервису компонента, включая сортировку по локальным индексам.
Как работает - см пример "printing_testcase".

Если потребуется использовать SQL-запросы - используйте TSqlite3Connection. Чтобы он пахал - достаточно положить в LIB-каталог (желательно) или каталог самой программы ( на крайняк ) 400KB Dll/So-ку. Очень хороший БД-движок ! Тоже есть простенький пример.

[Attid]

насколько я помню мартин не советует использовать локальный режим как БД только для локальной сортировки \ поиска или плохом конекте к БД. или что-то изменилось в его мнении ? думаю что нет, иначе он бы не брался за sqlite

если с БД не работал то Sqlite вполне хватит, если более серьезная ,l нужна, то тогда лучше firebird enembed.

[Alexander]

Спасибо ! Пока буду думать.

[debi12345]

насколько я помню мартин не советует использовать локальный режим как БД
==========
Для соизмеримых размеров данных - этот режим лучше, чем COMMA-SEPARATED.
А вообще, если нужно ХРАНИТЬ И ВЫБИРАТЬ данные - SQLite3, и никаких проблем.

[debi12345]

если с БД не работал то Sqlite вполне хватит, если более серьезная ,l нужна, то тогда лучше firebird enembed.
==========
Конкретно у embedded-режима ЖарПтицы - не вижу НИ ОДНОГО плюса . Разве что вложенные транзакции ( и то не уверен - есть ли они в этом режиме ).

А SQLite3 "вылизали" потому, что потребовалась SQL-совместимая замена DBF-формату - для использоваания уже отлаженных SQL-виджетов с локальными БД. Joost, мэйнтейнер FPC SQLDB - убеждал, что это невозможно, что работа с SQLite требует особого протокола и специальных DB-виджетов. Выходит - ошибался. При соблюдении простейших условий при создании таблиц - получаем соединение, полностью совместимое с PostgreSQL/FireBird и работоспособное с "заточенными" под них виджетами.

Не надо ставить SQLite3 в разряд БД начального уровня. Хотя бы потому, что он предлагает SQL-доступ с весьма сильным синтаксисом - вложенные запросы, UNION, все типы JOIN,.. Плюс любые типы данных и операции над ними, плюс транзакции (невложенные), плюс пользовательские функции, плюс триггеры, плюс юникод,... Неслабая фишка - можно распеределить БД по отдельным файлам - и собрать ее после после коннекта ( командой ATTACH ).

[alexs]

Конкретно у embedded-режима ЖарПтицы - не вижу НИ ОДНОГО плюса

в первую очередь приведи минусы - очень смелое заявление
отмазка о том что приходится с собой таскать модули от FB не принимается -0 они маленькие
а вот возможность прозрачной разработки приложения для вариантов однопользовательского или сетевого режимов - это очень хорошо
а как у SQLite3 с оптимизайцией запросов?
как он работает на больших данных? когда записей в соединяемых таблицах больше 10000? (amarok кажется использует SQLite3 - работает со списками песен медлено)

[debi12345]

Имеются ввиду плюсы перед другими локальными БД. Почему именно ЖарПтице отдать предпочтение ? В серверном ( нелокальном ) варианте - да, хороша - но все равно не PostgreSQL. Но embedded... Зачем такой изврат ?

а вот возможность прозрачной разработки приложения для вариантов однопользовательского или сетевого режимов - это очень хорошо
========
MSEgui пошла дальше. Ее CONNECTION-компоненты настолько совместимы, что можно заменить на SQLite3 прежний от Postgres, и наоборот.
( кстати, MSEgui's TIBConnection имеет специальную опцию для задействования embedded-режима. Мартин, автор MSegui - обожатель и агитатор ЖарПтицы. Поэтому она "вылизана" дальше некуда )

а как у SQLite3 с оптимизацией запросов?
как он работает на больших данных? когда записей в соединяемых таблицах больше 10000? (amarok кажется использует SQLite3 - работает со списками песен медлено)
========
Все нормально с оптимизацией. Есть режим просмотра планов выполнения запроса ( вроде PostgreSQL's EXPLAIN [ANALIZE] ).
Но как и с любой БД - нужно опциями настроек и созданием индексов минимизировать дисковый I/O - 99.99% причина замедлений. На том же PostgreSQL я получал ускорение в десятки-сотни раз. Причем индексы - штука хитрая, они иногда могут та-а-к-ие тормоза вызвать. Иногда их выключать надо - трюками вроде "where t1.a+0 > t2.b".

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

[debi12345]

Новинка SVN :

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

{
сделано через RTTI-анализ ( утиллитой "ppudump") входных и выходных аргументов всех public/published-методов компонентов; в работе не проверялось
}

[Attid]

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

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

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

по поводу локального режима процетирую мартина.

I think you misuse the dso_local mode of tmsesqldb. dso_local is thought to
do offline data edit of *small* data sets fetched from an SQL DB
(tmseibconnection or tmsepqconnection) and to apply the modifications to
the SQL database later, comparable how TClientDataset works. The locally on
disk logging of the modifications is done to be able to recover after
program crashes or if it is impossible to connect the DB and to apply and
commit the modifications before closing the program.
If you do not work with a server use tmsedbf or tmsesqlite3dataset as
dataset. It is planned to develop an tmsesqliteconnection later which can
be used with tmsesqldb.
Property packetrecords defines the record count of the fetched packages if
tmsesqlquery is in online mode.

Martin

[debi12345]

Тоже думал насчет "закладок" Именно поэтому и приставал к Мартину со встроенной птичкой. И все-таки несколько мегабайт - это многовато, если поддержка БД занимает в несколько раз больше самой программы.

Тонкостей и различий там почти и нет. Кто сам не пощупал MSEgui-вариант SQLite3 в работе - не совсем понимает, о чем речь идет. Ничего общего ни с FPC SQLDB, ни с ZeosDBO. Тот же SQL - причем весьма навороченный. И скорость на немонстроидальных данных - практически мгновенная.
А не-SQL хранение данных предоставляется как раз локальным режимом. Он же реализует задачи MemDataSet. Это Мартин круто придумал - сколько зайцев разом...

А вообще здорово, что у нас появился столь широкий выбор и варианты на все случаи жизни - и все ( включая BLOB ) работает на ура.

ПС:
Команде Лазаруса бы столь упорный и въедливый подход к расстановке приоритетов и тестированию. Был бы Линукс обеспечен средствами разработки под самое "не хочу". Эх, мечты...
Вы, что ли - возьмитесь за дело конкретно, по-мужски так, а ?

[debi12345]

Новости:
1) сделана поддержка BLOB & MEMO полей для MySQL (экспериментально);
2) добавлен компонент TWindowWidget - для нужд независимой отрисовки ( средствами OpenGL,... )