Выбор из динамического списка checkbox - кто как реализует?

[delphicoding]

Здравствуйте!
В БД есть таблицы ТД и ТЮ с некими данными, а также ТС где должны храниться связи отдельных записей ТД с записями ТЮ. В программе есть 3 окна - 1.Каталог берущий данные из ТД, 2.Редактор конкретной записи ТД, 3.Список выбора связей этой записи с некими другими данными при помощи checkbox сохраняется в БД в таблицу ТС. Юзер открывает 1.Каталог и выбирает нужную запись, открывает 2.Редактор и правит там данные - всё очевидно. Вопрос со списком выбора - как его правильно реализовать? как правильно построить логику сохранения списка и хранения выбранных связей в БД при условиях, что:
- обе таблицы ТД и ТЮ изменяются пользователем - дополняются, редактируются и удаляются.
- при открытии в редакторе записи ТД, юзер должен видеть полный список ТЮ с возможностью поставить напротив каждой записи галочку.
- второстепенно - желательно уменьшить объём хранимых данных в БД и упростить саму БД по возможности.

PS Как быстрее работает - если хранить каждую связь таблиц отдельной записью в отдельной "таблице связей ТС" или если хранить в одном поле таблицы ТД весь список и затем парсить его в БД при необходимости (во втором случае отсутствует необходимость в поиске-выборке, отсутствует таблица и все данные ТС)?

[Аватар]

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

[delphicoding]

Видимо да, но объём лишних данных и процедур несколько огорчает.

В частности пока не очень понял как записывать выбранные значения в БД в таблицу ТС? Подробнее - чтобы отобразить пользователю список всех ТЮ - в БД при помощи хранимой процедуры склеиваем ТЮ и ТС, из ТС берутся значения "связь да/нет". Отправили в интерфейс - получили таблицу в которой видно все ТЮ и напротив используемых стоит галочка из ТС. Всё понятно. Далее юзер ставит/убирает галочки в интерфейсе показывая какие связи ему нужно записать в БД - понятно. А вот как это дело обратно записать в БД непонятно тк это же не прямая правка реальной таблицы, а правка в таблице собранной из нескольких и значение не одно, а список, каждая строка которого - новая строка в таблице ТС. То есть задача типа "delete or insert" - но как это реализовать не очень понимаю... возможно опять таки при помощи ХП, но она же обработает только одну строку, а не все. Можно было бы использовать отправку в БД сразу по нажатию на галочку то есть редактировать каждую строку ТС по-отдельности, но только для редактирования, тогда как при создании новой записи ТД в 2.Редакторе ещё неизвестен номер будущей записи ТД и поэтому в ТС записать без номера ТД не получится - поэтому нужно записывать связи ТС сразу все скопом. (используются FIBplus и FB) Подскажите, пожалуйста, как это реализовать!

[Аватар]

Видимо да, но объём лишних данных и процедур несколько огорчает.

Поверьте, вас еще больше огорчит работа со строковым списком. С теми компонентами, что вы указали не знаком, а в принципе, что мешает по каждой операции вставки, удаления, корректировки записей как основных таблиц, так и таблицы-связки сразу редактировать соответствующие таблицы? Используя, например, ADOQuery и соответствующие SQL-команды. Зачем плодить хранимые процедуры? Что дают они в этом случае?

[delphicoding]

Можно и без ХП, это мне без разницы.

Просто не очень понимаю как реализовать delete or insert связей в ТС да ещё когда создаётся новая запись и ТД_ID неизвестен до момента записи в самой БД...

[Аватар]

Delete в TC очень просто через триггера на удаление записей основных таблиц. Вставив новую запись в основную таблицу, идентификатор в ней видимо автоинкриментный, тут же выдерните из базы максимальное значение этого идентификатора - это и будет ваш неизвестный ID. Такой механизм для работы с базой одновременно нескольких пользователей мне не нравится. Поэтому и не использую автоинкриментность, а сам уникальные идешки формирую

[delphicoding]

Это криво именно из-за работы нескольких юзеров. Триггер имхо ничем не лучше ХП, а только хуже.

Нет, нужно сделать именно так, как я описал выше, только я не знаю как это сделать...

Для получения правильного номера новой вставленной записи ТД можно использовать RETURNING, но мне кажется работать он будет исключительно внутри самой БД и в программу обратно он никак не дойдёт, в частности тк FIBDataset просто не станет принимать никаких ответов после Post... в общем я не очень понимаю как эти связи обратно insert or delete в БД ???

[Аватар]

А SELECT MAX(id) FROM ... уже отменили?

[delphicoding]

Если два юзера А и Б одновременно создают разные новые записи ТД, спрашивают maxid ТД, а затем отправляют данные ТС на insert... что получится??? хрень получится - мало того, что связи отправленные юзером Б перезапишут/дополнят связи записанные юзером А, так ещё и у записи ТД отправленной юзером Б вообще не будет связей в ТС!

И вообще использовать Max(ID) некорректно, тк если ранее была добавлена запись 100, а затем удалили записи 91-100, то значение Max(ID) выдаст 90, тогда как правильное значение которое задаст Генератор - 101 !!! Так что ваш вариант не подходит.

[evg_m]

Если два юзера А и Б одновременно создают разные новые записи ТД, спрашивают maxid ТД

то у этих записей с вероятностью 99% будут разные текстовые наименования (те данные, которые пользователь вводит в окне 2 редактор записи ТД).

select MAx(id) from TД where nametd =....

получит правильные идентификаторы для каждого пользователя.

если пользователи вводят одинаковые товары в каталог, то нужны или административные меры или нормальные средства поиска в каталоге, а не показывать ВСЕ записи в окне 1 (список товаров).

И для одинаковых товаров без разницы кто ввел их связи.

отправленные юзером Б перезапишут/дополнят связи записанные юзером А, так ещё и у записи ТД отправленной юзером Б вообще не будет связей в ТС

Все равно одна записей о товаре будет лишней и потребует своего удаления.