Как в Libre Office Base попроще организовать поле «тэги» с множественным выбором и автозавершением при вводе?

Question

[ITicDigger]

Хочется создавать таблицы типа:

Автор     | Произведение       | Жанры             | метки 
Оксана Н. | Мои любимые  гвозди| Хоррор, Мелодрамма| не пересматривать, посоветовать друзьям
Tommy N.  | Сельская печень    | Док., Триллер     | скинуть родителям

Хочу понять, есть ли в Libre Offise Base какой нибудь удобный механизм для наиболее простого и быстрого создания полей типа "жанры" или "метки", (короче тэгов) в которых подразумевается хранение нескольких тэгов, чем нибудь разделённых, да ещё чтобы они при добавлении брались из ранее введённых, имелась возможность потом при помощи них фильтровать данные, делать выборки и всё такое. Ещё бы неплохо чтобы при отсутствии в списке "ранее введённых" такой тэг после ручного ввода сам добавлялся куда надо (пополнял список ранее введённых)?

Comments

[Константин]

Удалось найти решение?

[ITicDigger]

Константин, Нет. В итоге реализовал по старинке через связанные таблицы, самые вкусные фичи реализовать не удалось. Промучился с этим Libre Office Base ещё несколько месяцев и устав от бесконечных граблей решил раз и навсегда отказаться от него. Жаль но не помню что стало последней каплей. Помню только что это было что-то очень веское.

[Константин]

ITicDigger, Отказаться то конечно можно в пользу других продуктов. Мне хотелось создать базу фильмов, чтобы ее можно было открыть на разных ОС, но все никак не разберусь с этим LO. Жуть какой неудобный

[ITicDigger]

Константин, Недавно наткнулся на свои манускрипты из двухгодичного прошлого, в котором я пытаюсь остановить себя из будущего, чтобы не юзать больше LO Base) Не знаю поможет ли это вам отправиться на поиски чего получше но всё же:
- Глючный движок не обновляемый веками,
- Плохая документация,
- "Движок HSQLDB - непригоден даже для обучения, потому как имеет жуткие странности. Не буду их перечислять. HSQLDB оказался очень требователен к явной группировке для агрегирующих функций - нужно упомянуть все(!) столбцы, SELECT-запросы в нем очень "многословны" ист.: https://forumooo.ru/index.php?topic=5827.0
- Нет GROUP CONCAT (очень тяжкий грех)
- нельзя переименовывать таблицы и запросы рассчитывая что связь с использующими их запросами, отчётами, формами сохранится.

Это конечно далеко не всё. Помню как меня вымораживали краши при работе с дизайнером формы, убивавшие всю работу между сохранениями. Причём там какая-то довольно неочевидная система сохранений была из за которой я постоянно думал что сохранился но... Краш - и снова от моей формы чистый лист. Там кажется нужно было сейвится в главном окне LO а не в окне Формы.
Редактор SQL тоже "радовал" неуменем делать автотабуляции и вообще удалением любых табуляций.
При сообщении об ошибке не указывалась строчка в запросе.

PS кстати у меня БД как раз для хранения фильмов на ней таки была реализована в те мрачные времена, до сих пор валяется без надобности, после осознания что ведение картотеки годных фильмов - пустая трата времени (за всю историю я обратился к ней всего один раз чтобы посоветовать кому-то фильм:)

[Константин]

ITicDigger, А еще нельзя поля в таблицы перемещать. Приходится удалять всю таблицу и заново создавать поля в нужной последовательности. Конечно их последовательность не имеет значения никакого, но лично для меня так удобнее. А на счет годных фильмов согласен, на текущий момент веду небольшой список в гугл таблицах, опять же для того, чтобы раз в сто лет кому-то что то из него порекомендовать. Базу для фильмов решил выбрать как пример с целью изучения LOB, но это откладывается еще на 10 лет, пока не допилят годный продукт.