Конвертация из dat в tps

yuriy

Доброе утро

Есть ли такая возможность сконвертировать базы данных из dat в tps

Игорь Столяров

ДД !
1. Создаёте словарь на основании структуры файлов DAT.
2. Делаете копию описания файлов и меняете формат на TPS.
3. Пишите конвертер (в С63 кажется была даже автогенерация такого кода) который тупо прогоняет
списки и выполняет присваивание TPSFile.Record :=: DatFile.Record (+ Blob/Memo поля если есть)
4. Всё.

yuriy

Спасибо
Буду пробовать

kreator

yuriy, а зачем это нужно? Я понимаю ещё в SQL базу какую-нибудь. Думаете tps намного лучше?

finsoftrz

Главный плюс tps это быстрые транзакции. В dat на порядок медленнее. Ну а еще более высокая скорость чтения по индексу и меньший размер данных, так как в
tps записи переменной длины. Я бы еще добавил, что tps практически полностью совместим по принципам работв с btrieve, при соблюдении некоторых несложных правил можно одно и тоже приложение динамически переключить с tps на btrieve. Например, если у нас сильно растет база данных, это позволяет решить проблему без переделки приложения - проверено на практике, работает хорошо.

Игорь Столяров

Я бы ещё добавил, что для TPS есть:
1. TPSFix / TPSScan, которые позволяют хоть как-то манипулировать содержимым файлов и решать некоторые проблемы при разрушении;
2. BLOB поля для работы с бинарными объектами, текстами, картинками ...

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

Я попробовал недавно использовать встроенный драйвер SQLite по назначению - т.е. хранить настройки программы.
Ну то, что нет поддержки Unicode - это понятно. Но сразу понеслись ошибки с доступом к файлам в папках с русскими
именами и пробелами.

Кстати, такая же засада была с драйвером Btrieve лет 15-20 назад. Потом исправили ....

kreator

Зато dat-файлы сами восстанавливаются при сбое. Достаточно файлы ключей удалить. А с tps так не получится. Ещё не упомянули возможность tps всё хранить в одном файле. Вроде круто, но не практично.

Про скорость не скажу. И MS SQL Express тоже встроенный (почти) и бесплатный.

После ~15 лет работы с MS SQL (MAV) смотреть на файловые базы без слез невозможно...

finsoftrz

kreator писал(а): ↑29 Декабрь 2023, 18:46 Зато dat-файлы сами восстанавливаются при сбое. Достаточно файлы ключей удалить.

Так можно восстановить сбои в ключах. Если произойдет проблема с записями, то при tps практически всегда будет верифицирован сбой, а при dat потеря записей останется незамеченной, пока программа не попытается получить к ним доступ. У dat плюс устойчивость к сетевым сбоям в файл-серверном режиме и выше скорость чтения по записям (без использования ключей). А это давно уже не актуально.

finsoftrz

Admin писал(а): ↑30 Декабрь 2023, 1:10 После ~15 лет работы с MS SQL (MAV) смотреть на файловые базы без слез невозможно...

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

kreator

Создатель поста молчит к сожалению. Я просто хотел заметить, что, если 30 лет назад не дошли руки до конвертации dat в tps, то может уже и не надо?

finsoftrz писал(а): ↑30 Декабрь 2023, 12:59
Admin писал(а): ↑30 Декабрь 2023, 1:10 После ~15 лет работы с MS SQL (MAV) смотреть на файловые базы без слез невозможно...
Для эффективной работы с файловыми базами надо использовать возможности кодогенерации клариона. Можно создать слой функций для работы с базой данных, используя содержимое словаря, включая пользовательские опции. В стандартных шаблонах только самый минимум.

Дело не в кодогенерации и не в шаблонах и не в классах. Там всего достаточно. Скорость файловой БД может ещё как-то сравниться с SQL только в однопользовательском режиме, и наверно на небольших базах. Всё остальное (безопасность, удобство, возможности) просто не сравнимы.
А в SV могли бы из tps сделать аналог SQLite. Надо было прикрутить прямой SQL-синтаксис (не через ODBC).

finsoftrz

Я могу сравнивать и вижу, насколько мало функционала в шаблонах из стандартной поставки. На вскидку, 15-20 процентов от потребности реальных приложений. Остальное ручками или через сторонние шаблоны. Плохо или нет это, вопрос другой. Вряд ли можно сделать что-то такое, что всех бы удовлетворило. У нас есть возможность создавать классы и шаблоны, никто не ограничивает, было бы желание и драйв.

Чтобы сравнивать isam и sql, надо понимать основы этих технологий. Isam работает с записями, sql с выборками. Isam это библиотеки с набором примитивных операций чтения и модификации данных, всю остальную функциональность обеспечивает приложение, которое работает с данными. Sql сервер это отдельное самодостаточное приложение, в котором много собственного функционала.
Sql будет работать тем быстрее, чем больший объем данных обрабатывается в рамках одного запроса. Isam будет работать тем быстрее, чем более интерактивно приложение, то есть чаще читает или модифицирует небольшие порции данных. Исходя из этого, если с sql работать как с isam, то это будет медленно и неэффективно. Аналогично и в другую сторону.

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