Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

12 Май 2021, 18:12 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Часто задаваемые вопросы по LibreOffice и Apache OpenOffice.org
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1 2 »   Вниз
  Печать  
Автор Тема: Помогите найти книгу по Base  (Прочитано 708 раз)
0 Пользователей и 1 Гость смотрят эту тему.
eeigor
Форумчанин
***
Offline Offline

Пол: Мужской
Сообщений: 549



« Стартовое сообщение: 25 Апрель 2021, 15:13 »

Roberto Benitez "Database Programming with OpenOffice.org Base & Basic"

В эл. виде
« Последнее редактирование: 25 Апрель 2021, 15:58 от eeigor » Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
economist
Форумчанин
***
Offline Offline

Сообщений: 1 457


« Ответ #1: 25 Апрель 2021, 18:30 »

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

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

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

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

Пол: Мужской
Сообщений: 549



« Ответ #2: 25 Апрель 2021, 18:41 »

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

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

@economist, расскажите о своём опыте поподробнее, плиз…
« Последнее редактирование: 25 Апрель 2021, 18:44 от eeigor » Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
kompilainenn
Мастер
*****
Offline Offline

Сообщений: 3 266



« Ответ #3: 25 Апрель 2021, 19:13 »

Совсем плох. Юзать только как морду к внешней бд
Записан

Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут
eeigor
Форумчанин
***
Offline Offline

Пол: Мужской
Сообщений: 549



« Ответ #4: 25 Апрель 2021, 19:56 »

Разбираться в этом чересчур сложно
http://www.access2base.com/access2base.html
Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
economist
Форумчанин
***
Offline Offline

Сообщений: 1 457


« Ответ #5: 25 Апрель 2021, 20:02 »

Опыт мой по 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
Форумчанин
***
Offline Offline

Сообщений: 1 457


« Ответ #6: 25 Апрель 2021, 20:08 »

Разбираться в этом чересчур сложно
http://www.access2base.com/access2base.html


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

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

Пол: Мужской
Сообщений: 404


WWW
« Ответ #7: 25 Апрель 2021, 21:11 »

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

Владимир.
eeigor
Форумчанин
***
Offline Offline

Пол: Мужской
Сообщений: 549



« Ответ #8: 25 Апрель 2021, 23:03 »

Да, это кое-что. Не совсем понятно только, что лучше: через Access2Base или использовать непосредственно API?
Подступиться сложно...
« Последнее редактирование: 25 Апрель 2021, 23:09 от eeigor » Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
economist
Форумчанин
***
Offline Offline

Сообщений: 1 457


« Ответ #9: 26 Апрель 2021, 09:08 »

Оба пригодятся. А что именно нужно? Вот я сделал из практики вывод, что приложение 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
Форумчанин
***
Offline Offline

Пол: Мужской
Сообщений: 549



« Ответ #10: 26 Апрель 2021, 12:22 »

@economist, да, интересно. Но нужно время для осмысления. С удивлением прочёл, что вы себя отнесли к непрограммистам. Можете привести пример формы во внешнем ODT (screenshot)?
« Последнее редактирование: 26 Апрель 2021, 12:40 от eeigor » Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
economist
Форумчанин
***
Offline Offline

Сообщений: 1 457


« Ответ #11: 26 Апрель 2021, 13:17 »

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

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


* ПримерODTформы.jpg (93.84 Кб, 1508x945 - просмотрено 9 раз.)
Записан

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

Сообщений: 1 457


« Ответ #12: 26 Апрель 2021, 13:30 »

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

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


* SearchInForm.jpg (9.1 Кб, 678x169 - просмотрено 6 раз.)
Записан

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

Сообщений: 1 457


« Ответ #13: 28 Апрель 2021, 14:52 »

А вот и книжка

* !КНИГА - Разработа в OO Basic Database BASE.pdf (570.68 Кб - загружено 9 раз.)
Записан

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

Пол: Мужской
Сообщений: 549



« Ответ #14: 28 Апрель 2021, 15:48 »

@economist, спасибо. Полагаю, найти было непросто!
Я обе посмотрю (+Питоньяк, ссылка от @sokol92).
Я знаю Access (и старую DAO, и ADO, и всё прочее). Просто думаю, стоит ли вставлять лишний слой для доступа к объектам. Но Access2Base раскрывает секреты API
« Последнее редактирование: 28 Апрель 2021, 15:53 от eeigor » Записан

Ubuntu 18.04 LTS • LO 7.1.1.2 Community
Страниц: 1 2 »   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!