Страница 1 из 1

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

Добавлено: 27 Декабрь 2023, 3:51
yuriy
Доброе утро

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

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

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

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

Добавлено: 27 Декабрь 2023, 16:37
yuriy
Спасибо
Буду пробовать

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

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

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

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

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

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

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

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

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

Добавлено: 29 Декабрь 2023, 18:46
kreator
Зато dat-файлы сами восстанавливаются при сбое. Достаточно файлы ключей удалить. А с tps так не получится. Ещё не упомянули возможность tps всё хранить в одном файле. Вроде круто, но не практично. :) Про скорость не скажу. И MS SQL Express тоже встроенный (почти) и бесплатный.

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

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

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

Добавлено: 30 Декабрь 2023, 12:27
finsoftrz
kreator писал(а): 29 Декабрь 2023, 18:46 Зато dat-файлы сами восстанавливаются при сбое. Достаточно файлы ключей удалить.
Так можно восстановить сбои в ключах. Если произойдет проблема с записями, то при tps практически всегда будет верифицирован сбой, а при dat потеря записей останется незамеченной, пока программа не попытается получить к ним доступ. У dat плюс устойчивость к сетевым сбоям в файл-серверном режиме и выше скорость чтения по записям (без использования ключей). А это давно уже не актуально.

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

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

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

Добавлено: 30 Декабрь 2023, 14:25
kreator
Создатель поста молчит к сожалению. Я просто хотел заметить, что, если 30 лет назад не дошли руки до конвертации dat в tps, то может уже и не надо?
finsoftrz писал(а): 30 Декабрь 2023, 12:59
Admin писал(а): 30 Декабрь 2023, 1:10 После ~15 лет работы с MS SQL (MAV) смотреть на файловые базы без слез невозможно...
Для эффективной работы с файловыми базами надо использовать возможности кодогенерации клариона. Можно создать слой функций для работы с базой данных, используя содержимое словаря, включая пользовательские опции. В стандартных шаблонах только самый минимум.
Дело не в кодогенерации и не в шаблонах и не в классах. Там всего достаточно. Скорость файловой БД может ещё как-то сравниться с SQL только в однопользовательском режиме, и наверно на небольших базах. Всё остальное (безопасность, удобство, возможности) просто не сравнимы.
А в SV могли бы из tps сделать аналог SQLite. Надо было прикрутить прямой SQL-синтаксис (не через ODBC).

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

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

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

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