Помогите найти книгу по Base

Автор eeigor, 25 апреля 2021, 15:13

0 Пользователи и 1 гость просматривают эту тему.

eeigor

Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community

economist

Книга старая, оф-но в эл. виде не выходила, а скан, похоже, не "просочился". Ссылки из сети - проблемные.

Думаю что это не страшно, т.к. с выходом библиотеки Basic/Python c названием Access2Base - были реализованы почти все методы MS Access, а значит надо искать книжку по Access :-)

К тому же Base в 2007 г. - это было нечто ну очень сырое. Все что требуется от Base в OpenOffice|LibreOffice - это поддерживать бридж между БД и офисными приложениями, и эта функция (Ctrl+Shift+F4 и doImport) - работает нормально. Все остальное - можно сделать либо на самом SQL, либо на том же Python, который может работать с БД своими методами, либо нашкодить в Basic, опираясь на оф мануалы и подглядывая в Access2Base.     
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

eeigor

#2
Что, Base совсем плох? Ругают сильно...

Что лучше использовать для хранения самих данных, чтобы не потерять? HSQLDB, если побольше, и SQLite, если поменьше?

@economist, расскажите о своём опыте поподробнее, плиз...
Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community

kompilainenn

Совсем плох. Юзать только как морду к внешней бд
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

eeigor

Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community

economist

Опыт мой по SQLite невелик, но исключительно на своих кейсах уже длится лет 12. Base не плохой, он своеобразный. Все что от него требуется - передать SQL-команду дальше, в движок, а с этим он справляется сносно.

SQLite через ODBC/JDBC, базы на расшареннных по сети SSD по 3-5 Гб - летают. SQLite примерно в 3-4 раза быстрее всех остальных вариантов (FireBird, MySQL, PostgreSQL), даже при 1-3х-пользовательском подключении к одному файлу *.sqlite по сети. Большие вставки и чтения - лучше делать силами Python (его C-модуль sqlite3 - в 5 раз быстрее чем ODBC/JDBC-драйвера и чуть быстрее даже родной консольной С-утилиты sqlite3.exe). Но даже без питона все летает, а запросы пишутся легко. SQLite хранит всё как текст, это позволяет шкодить, невзирая на типы. В числовой столбец запишется текст, в текстовый - дата итд. Можно писать так SELECT 1, 3, фио FROM TABL1     GROUPBY отдел - и увидим последнюю фио в каждом отделе - всяких Яшиных итд. Другие движки - выдадут ошибку, и многих это неиллюзорно бесит.

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

Если записи в БД редки и незначительны, а чтения часты и объемны - SQLite, возможно, лучшая по скорости БД. Она же супер-решение, если данные хранятся еще где-то (например в 1С). Я убил файл БД лишь раз (оказалось что сыпался SSD, но возможно эти вещи были связаны).

А еще SQLite поддерживает виртуальные таблицы, линковку с TXT/CSV/TSV, вычисляемые столбцы, оконные функции - т.е. все современные фишки самых модных RDBMS. Есть ещё место для небольшого тюнинга (PRAGMA-команды, кэш, IN-MEMORY базы, настройки драйвера, размещение БД на SSD RAID 0). Но 10 активных одновременных читателей - это уже много, 6-ть из них - вывалятся в таймаут и будут недовольно ждать. Полноценное клиент-серверное SQLite-приложение - да, можно найти или сделать, иcпользуя WAL-журнал и, скажем XML-RPC-модуль на том же Python. Но это напоминает подбор глобуса под сову.Хотя решений таких полно, включая серверные варианты SQLite, и даже распределенные решения (копия БД на разных хостах с синхронизацией по указателям файла).

Теперь про серверы БД. Опыта у меня тут меньше, но я сравнивал те же данные и объемы, что и под SQLite.  
FireBird слегка сложноват в установке на зоопарке Windows (2 компонента), зато MySQL/PostgreSQL имеют хорошие стабильные "родные" LO-коннекторы из коробки. И в целом эта троица может удовлетворить все многопользовательские кейсы. Просто тут уже не обойтись без настройки сервера БД, дефолтные настройки дадут небыстрый отклик из-за кучи флагов безопасности. Если активных пользователей больше 100, я бы сразу смотрел на Постгресс, но только если дадут порулить сервером. Тема сложная, требует глубокого погружения.    

HSQLDB - мало того что глючен (зависания, вылеты), так ещё и требователен к SQL-запросам в части явной агрегации итд). Его дублирующиеся SQL-функции - в работе часто ставят в тупик, я бы даже в качестве учебной её не советовал. Даже FireBird Embedded лучше - он в 5 раз быстрее. Но с TXT/CSV - FireBird Embedded не работает, а простой FireBird - ограниченно, только дозапись, без индексов, поля фикс длинны. Могу ошибаться, проверял год назад.
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

economist

Цитата: eeigor от 25 апреля 2021, 19:56Разбираться в этом чересчур сложно
http://www.access2base.com/access2base.html


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

sokol92

У А.Питоньяка есть книга по Base начального уровня AndrewBase.odt
Владимир.

eeigor

#8
Да, это кое-что. Не совсем понятно только, что лучше: через Access2Base или использовать непосредственно API?
Подступиться сложно...
Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community

economist

Оба пригодятся. А что именно нужно? Вот я сделал из практики вывод, что приложение Base вообще не должно появляться на экране у юзера, и проблем с ним не будет. Для этого применяем осознанную тактику:

- Формы рисуем не внутри ODB, а сразу во внешнем ODT (огромный плюс - это просто красиво и перекрытием форм можно совместить данные из разных БД в одном скрине - у меня на одной странице-диалоге видны TXT+SQLite+DBF базы). Плюс мы получаем привычную "печатную форму" документа с "текстовыми" контролами (список/поля/переменные/формулы/св-ва юзера), проверкой орфограмматики, переносами и возможностью ручного форматирования. В Base всего этого - нет;   

- Авторегистрируем все нужные БД макросом по пути ODT (рядом или глубже лежит и ODB) при первом открытии файла (и просим переоткрыть ODT юзера для TXT-баз, иначе не обновятся);

- Данные в/из ODB - берем макросом. Для Calc - методом doImport. В ODT - чтением ResultSet или перебором "окна" RecordSet;

- Для формирования "серий" документов - годится интерактивная штатная "рассылка/циркулярное письмо", работает, если "задерживать дыхание", на 10000 получателей - норм. Это еще один довод за ODT, а не за ODS в качестве "морды". Зато общий "реестр" или журнал - вполне будет в ODS в виде DatabaseRange автообновляться при открытии, и этих ODS м.б. много, по числу пользователей. У каждого в ODS свои фильтры полей, автофильтр итп. Но данные целиком грузятся при открытии - из общей БД. Т.е. "форма журнала" и "форма ввода" в БД - это ODS и ODT файлы.   

- Широко используем XGRID control (Таблица) - как разумный компромисс между скоростью и красотой в пользу скорости. На Форуме полно примеров для старта;

- Библиотеку макросов размещаем в сети с self-сертификатом, шифруем, а если решение на продажу - выносим check-функции в библиотеку Python, её обфусцируем, паролим и привязываем к железу готовой библиотекой типа pyarmor (под python всегда есть что-то готовое и оно точно бесплатное);

- Python дает быструю альтернативу записи/чтения во все RDBMS, но его высокоуровневые либы типа Pandas - не установишь во встроенный в LO Python из-за того что тот кастрирован и собран без нужных флагов, С-типов и прочего. Скилла тут мне не хватает, а судя по Сети - никто Pandas под встроенным Python запустить так и не смог. Сделано это намеренно разрабами LO, чтобы избежать конкуренции (думаю они просто поленились потестить :-))

- А вот использовать внешний Python - упаришься с вызовом из Basic/Shell/oSvc. Тут, вероятно, придется юзать зоопарк Shell, BAT, VBS, stdout и прочие "прелести" винды. Правда, не исключаю что самое простое решение под носом, просто никто его так не описал, как это делаю я, ну для таких же как я - непрограммистов;

- Но можно использовать простые либы во встроенном Python (csvtable, csvtotable итд), особенно если часть данных предназначена только для чтения. Макросы на встроенном Python можно дергать из кода Basic и с отладкой тут поможет расширение APSO.

В общем, Формы - в ODT/ODS, побольше Python, делиться опытом - и работать можно. Учитывая что ядро приложений у LO общее - мы экономим ресурсы по сравнению с MSO и не смотрим в глючный Base.

Отладка самих же SQL-запросов - возможна в десятке более красивых (чем Base) свободных или free инструментах. Для SQLite это SQLiteSpy, SQLiteDatabaseBrowserPortable, SQLite Expert итд.
   
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

eeigor

#10
@economist, да, интересно. Но нужно время для осмысления. С удивлением прочёл, что вы себя отнесли к непрограммистам. Можете привести пример формы во внешнем ODT (screenshot)?
Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community

economist

Думал что будет наглядней. Ну вот например, ODT Форма Заявки в отдел закупок, вверху - данные из БД в формате TXT (readonly, файлик 5Мб лежит на сетевой шаре) в контроле XGRID, он нужен для быстрого подбора того, что нужно купить из списка 100 тыс строк ранее сделанных покупок (взяты из 1С, обработаны Pandas). Подбор даже в такой базе работает мгновенно (у XGRID свой фильтр, фильтр учитывает текущее выделение и добавляет его через AND). Нижняя таблица - заполняется из верхней, в пару кликов мышью (когда осталась одна строка - запрашивается кол-во и строка попадает в Заявку). И все это записывается в БД SQLite макросом.

Чем хорош ODT - можно воссоздать вид бумажного дока, и даже напечатать, для некоторых это важно. И если текста много (например договор) - то можно на стилях и переносах сделать красиво (серые поля документа - тоже переносятся!). По сравнению с тем что делает 1С и 99% всех EDM - верстка во Writer на стилях - просто божественно опрятна.
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

economist

Всегда полезно реализовать быстрый поиск по первым символам/подстроке, как на предыдущем скрине, в отдельных текстовых полях. Если сравнивать число кликов на подбор в 1С и тут, в ODT-форме - то разница 4:1. И по времени то же самое.     

Правда, по-чесноку - примерно 1/3 юзеров ныряет по старинке в панель Навигация формы. Это крупные кнопки вверху, которые позволяют Сортировать, Фильтровать (в т.ч. многокритериально) и искать по любым реквизитам достаточно удобно в отдельных стандартных окошках. Его стоит закрепить для всех вверху  (см. скрин Панели).   
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

economist

Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

eeigor

#14
@economist, спасибо. Полагаю, найти было непросто!
Я обе посмотрю (+Питоньяк, ссылка от @sokol92).
Я знаю Access (и старую DAO, и ADO, и всё прочее). Просто думаю, стоит ли вставлять лишний слой для доступа к объектам. Но Access2Base раскрывает секреты API
Ubuntu 18.04 LTS • LibreOffice 7.5.1.2 Community