Сабж. LibreOffice 3.4.3
1. Хранение файлов в базе. Насколько hsqldb устойчива к работе с тяжёлыми файлами? То есть, какой размер базы ещё позволяет нормально с ней работать?
2. есть две таблицы. Table1 {t1_id, ...}, Table2 {t2_id, field1, field2}
Пытаюсь настроить связи между таблицами, хочу связать t1_id и field1, а также t1_id (естественно другую строку) с field2. Сервис » Связи позволяет это сделать, даже отображает, но при сохранении теряет одну из связей. Что я делаю не так?
3. Запросы и представления. Тут уже явно не base, а SQL чистой воды.
Есть структура из следующих таблиц:
t_marker {m_id, m_name}
t_example {e_id, e_name}
t_seq {s_id, s_m_id, s_e_id, s_seq}
Где соответственно s_m_id и s_e_id связи с соответствующими ключами.
Нужно сделать следующую таблицу:
m_name | s_seq (s_m_id==m_id && m_name=="1") | s_seq (s_m_id==m_id && m_name=="2") |
То есть, одну ячейку поместить в два столбца, в зависимости от имени m_name. При этом, s_seq может и не быть, но нужно показать все строки из t_example, вне зависимости от этого факта.
Понимаю, что нужно работать через outer join, но
SELECT "DNA-s"."Number", "Snails"."SnailStringID", CASE WHEN "COI"."Sequence" IS NULL THEN '' ELSE '+' END AS "COI", CASE WHEN "ITS"."Sequence" IS NULL THEN '' ELSE '+' END AS "ITS-S" FROM "DNA-s", "Snails", "Markers"
LEFT JOIN "Sequences" AS "COI" ON "COI"."DNAID" = "DNA-s"."DNAID" AND "COI"."MarkerID"="Markers"."MarkerID" AND "Markers"."MarkerName"='COI'
LEFT JOIN "Sequences" AS "ITS" ON "ITS"."DNAID" = "DNA-s"."DNAID" AND "ITS"."MarkerID"="Markers"."MarkerID" AND "Markers"."MarkerName"='ITS-S'
WHERE "DNA-s"."SnailID" = "Snails"."SnailID" ORDER by "DNA-s"."Number" ASC;
Выдаёт пустую таблицу, хотя по отдельности работает корректно. (запрос взят из рабочей базы, но надеюсь что идея понятна).
5. Можно ли расширить следующий пример, но задавать столбцы не вручную, а пройтись по тому, что есть в таблице marker автоматически?
1. hsqldb на "тяжелых" файлах я бы использовать не стал, лучше PostgreSQL или что-то подобное.
2. Составлять по вашему описанию таблицы с данными нет ни времени ни желания. Приложите пример вашей БД и конкретно покажите, что вам нужно.
1. Понял. А сконвертировать с hsqldb в PostgreSQL насколько сложно?
Ок. Таблица во вложении.
2. Таблица Sequences, поля PrimerForwardID и PrimerReverseID. Хотелось бы чтоб они связывались с таблицей Primers.
3. Собственно код описывает что хочется получить. Запрос «test_1»
[вложение удалено Администратором]
Все равно ничего не понятно, что вы хотите.
Что-то вроде этого?
[вложение удалено Администратором]
Да, почти.
Хочется получить подобное вот этому:
SnailStringIG as name
name | COI | ITS |
nenk-01 | + | + |
nenk-02 | | + |
nenk-03 | + | |
nenk-04 | | |
Отображены все SnailStringID, вне зависимости от того, есть ли соответствующие им записи в таблице Sequences.
Приложенный вами пример не соответствует вашим требованиям, например, отсутствуют nenk-03 и nenk-04, или, непонятно, откуда эта строка
name | COI | ITS |
nenk-01 | + | + |
Возможно ли выполнение запросов на обновление в BASE? Пишу запрос SQL:
Обновить пустое поле DATEADD в таблице REGISTR текущей датой
UPDATE REGISTR SET DATEADD = NOW WHERE DATEADD IS EMPTY
А комп выдает, что возможно только выполнение инструкции на выборку SELECT...
Как по другому можно решить эту проблему?
Задать значение текущей даты в самой таблице по умолчанию тоже не получается.
Цитата: Alexandr Polbin от 12 февраля 2017, 13:15UPDATE REGISTR SET DATED = NOW WHERE DATED IS EMPTY
Где вы берёте такой код? Из Access? Ищите ответы на ваши вопросы на нашем форуме (но не в ошибках новичков, а в правильных ответах), читайте документацию по соответствующей базе.
Цитата: Alexandr Polbin от 12 февраля 2017, 13:15Задать значение текущей даты в самой таблице по умолчанию тоже не получается.
Попробуйте (названия таблиц и полей надо брать в кавычки):
ALTER TABLE "REGISTR" ALTER COLUMN "DATEADD" SET DEFAULT TODAY
Kildor - забудьте про HSQL - это нерабочий вариант. Для себя давно решил что только SQLite через ODBC. А на вырост - встроенная FireBird3 или PostgreSQL через ODBC.
Alexandr Polbin - в Base есть 3 варианта запуска SQL-запросов:
1) Конструктор запросов с отжатой SQL
2) Конструктор запросов с нажатой SQL
3) Сервис - SQL
DDL-запросы "просятся" в третий вар-т или во второй.
Вообще, информацию брал в "Синтаксисе языка SGL".
На "ALTER TABLE "REGISTR" ALTER COLUMN "DATEADD" SET DEFAULT TODAY" тоже выдает синтаксическую ошибку.
А в режиме дизайна запросов я функции обновления что-то не нашел, может она называется как-то по-другому...
При запуске последней команды через сервис SQL пишет "Команда выполнена успешно", но поля в таблице не обновляются...
И как потом сделать, чтобы эта команда выполнялась каждый раз при добавлении в таблицу новой записи?
Цитата: Alexandr Polbin от 12 февраля 2017, 16:43
При запуске последней команды через сервис SQL пишет "Команда выполнена успешно", но поля в таблице не обновляются...
И как потом сделать, чтобы эта команда выполнялась каждый раз при добавлении в таблицу новой записи?
Эта команда устанавливает текущую дату по умолчанию, если в поле ничего не записано. Я дефолтные поля в форме ввода не отображаю.
Каждый раз не надо выполнять.
Alexandr Polbin - чтобы увидеть изменения в Таблицах - нужно их обновить вручную: Вид - Обновить таблицы.
Чтобы "команда выполнялась каждый раз при добавлении в таблицу новой записи" - курите триггеры. Но искренне надеюсь что вы это делаете не в HSQLDB. Иначе число проблем будет расти в геометрической прогрессии и всё равно приведет к отказу от HSQL в пользу чего угодно другого.
За SQLite ч/з ODBC/unixODBC - скажу что это самая быстрая база из всех RDBMS при работе с нею до 3-х человек по сети 100/1000 Гбит, да-да, в режиме файлового доступа. Плюс не нужны кавычки, как в примерах выше, и работает кириллица в таблицах, полях, псевдонимах.
OpenOffice|LibreOffice - разработчики могли бы использовать SQLite как основную RDBMS в Base. Но тогда из BASE получится 99% "убийца" Microsoft Access (12 тыс. руб.). А это, по теории заговора, кому-то не очень чтобы и нужно.
Цитата: economist от 13 февраля 2017, 09:31
OpenOffice|LibreOffice - разработчики могли бы использовать SQLite как основную RDBMS в Base. Но тогда из BASE получится 99% "убийца" Microsoft Access (12 тыс. руб.). А это, по теории заговора, кому-то не очень чтобы и нужно.
Здесь (https://bugs.documentfoundation.org/show_bug.cgi?id=38811) описана история вопроса (причины заговора указаны начиная с комментария 19 (https://bugs.documentfoundation.org/show_bug.cgi?id=38811#c19)).
mikekaganski - спасибо за ссыль, с удовольствием прочитал и воспрял духом.
Во-первых, FireBird3 - это хорошо, если даже не сказать прекрасно. Есть и документация на русском, и IDE от InterBase итд. FB быстрее HSQL в 3-5 раз, могу поискать пруф. Но всё это не повторит успеха "малопользовательского" MS Access, который основан на его безсерверной (читай - простой) природе. Именно это есть и у SQLite. "No admin", что называется.
Во-вторых, в тот треде - наглая ложь про сопоставимую скорость HSQLDB и SQLite. Предлагаю просто поверить мне на слово. У HSQLDB скорость в 3-4 раза ниже, чем у SQLite.
В-третьих, динамическая, а если точнее "утиная", "предлагаемая" типизация, применяемая в SQLite, Python, LUA итд - это как раз неимоверное благо. Вcё равно в коде люди реализуют проверки, CAST в SQL быстр, а сохранение всего как текст - вовсе не так уж плохо. Главное - что оно всегда работает и не вызывает никаких сбоев.
Вот такая фирма как 1С в своем продукте Предприятие 7.7 (1995-2018 гг) - все числовые коды хранит как текст, и ничо.
Мы, конечно, занимаемся офтопиком, и если можно, пусть админы уберуть это не относящееся к делу безобразие куда-нибудь... в другое место :)
Насчёт скорости - не знаю, и не считаю, что это значимо.
Насчёт утиной типизации - никто не спорит о том, что это удобно и хорошо для определённых задач. Однако суть проблемы не столько в некоем негативном отношении к концепции, сколько несовместимые изменения, требуемые в этом случае, либо реализация слоя абстракции, практически дублирующая множество функций, и гарантирующая свои баги в дополнение к уже имеющимся и бесплатно получаемым с любой внешней библиотекой.
Но что мне непонятно больше всего - это что мешает FireBird3 "повторить успех "малопользовательсткого" Access, основанный на его безсерверной природе"?
mikekaganski - да вовсе это не офтопик. Вопрос по Base, и шанс быть прочитанным, в контексте проблемы, будет здесь выше, чем в сугубо философском треде о движках.
Мне кажется, OpenOffice|LibreOffice не хватает всего лишь "нативного" доступа к SQLite, который реализовать, как мне кажется, несложно. А уж что по-умолчанию там будет создаваться - не важно. Я за 10 лет работы как внедренец всякого барахла - ни разу не столкнулся со сколь-либо серьезной базой на HSQLDB, а на JET/ICE - сотнями, на SQLite - десятками. Я не верю в работоспособность HSQLDB, поскольку количество "странностей" в ней - просто зашкаливает. Возьмем хотя бы избирательную работу функций в трех разных режимах запросов, непредсказуемое поведение при работе с TSV-файлами, коробочную монопольность доступа - и желание продолжать с HSQL моментально сходит на нет.
Успеху FireBird3 пока мешает то, что его еще прячут в экспериментальных возможностях LibreOffice (а ОО - неоо), и "безсерверным" его назвать нельзя. Все преимущества его проявятся только в серверном варианте. Который, как ни крути, требует вдумчивой настройки и 99% пользователей недоступен в силу воинствующего сисадминства.
Ещё раз: нативный доступ возможен только при условии огромной допработы для компенсации несовместимости. И это не "несложно". Но мы всегда рады любому вкладу!
Насчёт экспериментальности - не надо ерунду говорить. Пока идёт доводка - так и должно быть. И не надо смешивать в кучу в качестве "мешающих" фундаментальные проблемы и артефакты процесса внедрения (повторюсь: вы называете "мешающим" широкому внедрению часть самого процесса внедрения!)
А насчёт ""безсерверным" его назвать нельзя" - не понимаю. Мой вопрос, в общем-то, и был направлен на то, чтобы понять: что Вас в этом убеждает?
Наверное я не так выразился. SQLite-база, к которой подключен BASE через ODBC-драйверы - позволяет организовать совместную комфортную работу по LAN для 3-5 человек, а если "пишут" данные в таблицы только 1-2, то одновременно читать комфортно могут даже 8-10 человек, ну точь-в-точь как MS Access. При этом никакого "сервера" нет, файловый доступ работает под CIFS/SAMBA/NFS, т.е. на уровне ОС и очень даже стабильно.
HSQLDB в "серверном" режиме запускал, получил зримую деградацию производительности и всё там намного сложнее в администрировании. Это точно сложнее чем просто сетевая шара.
Для доступа к FireBird нужно как минимум установить клиента и ODBC-драйвер. Но за этим движком в LibreOffice большое будущее.
Стать вторым Аксессом (а Calc-у - вторым Экселем) мешает также неприменимость половины VBA-наработок без переписывания, хотя усилия разработчиков видны и очень помогают.
Цитата: economist от 13 февраля 2017, 13:33
Для доступа к FireBird нужно как минимум установить клиента и ODBC-драйвер. Но за этим движком в LibreOffice большое будущее.
Ну неправда ведь.
Вся эпопея с переходом на FireBird идёт через интегрирование его embedded сервера в ЛО. Хотя использовать подключение к внешнему серверу никто не мешает (и для серьёзного использования, естественно, предпочтительно, но мы ведь не об этом?)
Опять я не так понял. В общем, я рассматриваю embed/serverside FireBird как одно целое, потому что это - "новое" в LibreOffice. Если выбирать что делать embed - SQLite или FireBird, мой выбор сейчас, конечно, FireBird. Потому как работы там уже сделано много. А если бы такой вопрос возник 5 лет назад - лучше бы взяли SQLite...
Цитата: economist от 13 февраля 2017, 10:49Успеху FireBird3 пока мешает то, что ... преимущества его проявятся только в серверном варианте. Который, ... недоступен в силу воинствующего сисадминства.
Пять копеек в оффтоп.
Могу сказать, протестировав на собственной шкуре, что в силу воинствующих инструкций "сверху" недоступна даже возможность подвязать к LO Base базу SQLite через ODBC. А просто потому, что раздел "Администрирование" в панели управления Windows закрыт для простых смертных. Я уж молчу про то, что, например, деятельно желать LOo вместо OOo на рабочем месте может только извращенный любитель изматывающей эпистолярной формы общения с коллегами НЕзаинтересованных IT-подразделения, СБ и отдела защиты информации. Я к тому, что основная проблема всего доброго в борьбе со всем злым носит далеко не технический характер.
ost - я всю жизнь борюсь с сисадминами, AD и Group Policy, хотя админа могу просто вот так взять и уволить.
Тут, видимо, нужен некий компромисс и гибридный подход в бизнесе (безопасность vs саморазвитие).
Вот бы как в Linux - в своем профиле можешь хулиганить, как хош. Но с Windows - увы, так нельзя.
Как ни странно, некое успокоение в войне уровней дал корпоративный "репозиторий" portable-версий OO/LO и другого популярного софта, ес-сно только Free и СПО. Его "поддержкой" занимается куча простого люда, все с ограниченными правами. Дома пробуют, приносят на флешке, потом он оказывается у всех со статьей-ссылкой на корпоративную Wiki. За это есть разовая премия, поэтому инициатива "теплится" сама по себе.
Кстати, проблему отсутствия доступа к Администратору ODBC - можно решить под Windows даже с ограниченной учёткой - кодом на StarBasic внутри Base/Calc и DNS-less подключением по документации SQLite3ODBC driver.
Есть, конечно, общеизвестные способы правки реестра напрямую, способы повышения привилегий итд, но, имхо, лучше без этого. И всё-таки успехов в борьбе.
PS Сам-то, конечно, администратор домена, поэтому стараюсь почаще садиться за чужие компы, чтобы "вернуть чувство острого классового неравенства".