@morozovdenis интересный вариант, в плане того, что разделы получаются настраиваемыми под пользователя конкретного, а не под компанию.
Правильно понимаю, что в 1 варианте нужно контролировать сериализацию и обратный процесс на клиенте, при этом меняться будет N строк, где N - количество групп?
А во втором всё будет проще с контролем, но меняться будет больше строк - M, где M - количество элементов?
Структура БД планируется такая:
1. Все пользователи принадлежат какой-то компании
2. Каждый сортируемый элемент принадлежит какой-то компании
3. Элементы внутри компании могут быть собраны в группы
4. Позиция будет учитываться внутри групп
Элементы сортируются внутри группы и могут перемещаться между группами.
Например, для списка у компании №2:
- #1. Группа 1:
- - - #4. B
- - - #2. A
- - - #1. C
- #2. Группа 2:
- - - #3. D
- - - #6. F
- - - #5. E
У элементов (A, B, C, D, E, F) будет примерно такая структура (если отсортировать по ИД элемента):
C - id: 1, company_id: 2, group_id: 1, position: 2
A - id: 2, company_id: 2, group_id: 1, position: 1
D - id: 3, company_id: 2, group_id: 2, position: 0
B - id: 4, company_id: 2, group_id: 1, position: 0
E - id: 5, company_id: 2, group_id: 2, position: 2
F - id: 6, company_id: 2, group_id: 2, position: 1
@morozovdenis ага, понял про edit-save. Не подойдёт :)
Структура БД планируется такая:
1. Все пользователи принадлежат какой-то компании
2. Каждый сортируемый элемент принадлежит какой-то компании
3. Элементы внутри компании могут быть собраны в группы
4. Позиция будет учитываться внутри групп
Элементы сортируются внутри группы и могут перемещаться между группами.
Например, для списка у компании №2:
- #1. Группа 1:
- - - #4. B
- - - #2. A
- - - #1. C
- #2. Группа 2:
- - - #3. D
- - - #6. F
- - - #5. E
У элементов (A, B, C, D, E, F) будет примерно такая структура (если отсортировать по ИД элемента):
C - id: 1, company_id: 2, group_id: 1, position: 2
A - id: 2, company_id: 2, group_id: 1, position: 1
D - id: 3, company_id: 2, group_id: 2, position: 0
B - id: 4, company_id: 2, group_id: 1, position: 0
E - id: 5, company_id: 2, group_id: 2, position: 2
F - id: 6, company_id: 2, group_id: 2, position: 1
1. Каждый элемент принадлежит группе пользователей. То есть в рамках БД это отношение "один-ко-многим", а если так посмотреть, то доступ к элементам имеют несколько человек. Плюс планирую сделать прослойку для группировки элементов (это будет как-то так: группа пользователей [одна] - группы элементов [много] - элементы [много, но каждый элемент входит только в одну группу])
2. Про курсор хорошее дополнение, спасибо. А edit-save - это что значит?
@Sander_Li теперь спрашиваю себя, нужно ли вообще готовить в таком случае эти запросы.) Может быть, легче вместо 5-6 шаблонов для подготовленных формировать запрос на лету
Картина в целом: PHP-скрипт работает в качестве демона для сбора данных. В нём один раз готовится запрос при запуске, и дальше в бесконечном цикле данные вставляются по этому шаблону
@Sander_Li про генерацию запроса до подготовки как-то не подумал. Похоже, что только так и можно - а с уже сгенерированным запросом такая штука не прокатит.
У меня ситуация как раз такая: запрос один раз готовится и много раз выполняется по шаблону. Раньше приходили значения для всех столбцов и это работало - а теперь базу переделали, и какие-то значения теперь будут пустыми.
