Хранение порядка элементов HTML-списка в БД

Question

[Remmi]

Всем доброе утро!

Делаю сейчас HTML-страницу со списком элементов. Этот список загружается из базы данных MySQL, отрисовывается через шаблон, и потом его можно сортировать как душе угодно (с помощью JUI Sortable).

Возник вопрос: как лучше хранить данные о порядке элементов в БД? Сейчас в таблице с элементами 4 поля.
1. Стоит ли заводить дополнительное поле sort в таблице с элементами?
2. Или стоит сделать отдельную таблицу для хранения порядка элементов?

И дополнительный вопрос: как лучше записывать в БД новый порядок элементов?
1. Кэшировать данные на клиенте после перемещений и передавать на сервер после определённого таймаута (когда пользователь, например, уже N секунд ничего не сортировал в меню)?
2. Или можно сразу, если сортировки не так часто происходят?

Заранее спасибо всем, кто прочитал и откликнулся :)

Comments

[Remmi]

Структура БД планируется такая:
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

Answer 1

[Denis Morozov]

если элементы принадлежат исключительно одному пользователю, то заводите поле дополнителное order
если один и тот же элемент может принадлежать рзным пользователям, то поле надо заводить в таблице которая делает связь many-to-many между пользователями и элементами

по второму вопросу
1. сохранять данные по таймауту после последнего действия - это хорошее решение. можно ещё смотреть что пользователь увёл курсор с этого элемента
2. сразу отправлять можно конечно, но не желательно
3. ещё есть старое доброе решение edit-save, не вебдванольненько, но зато надёжно )

Comments

[Remmi]

1. Каждый элемент принадлежит группе пользователей. То есть в рамках БД это отношение "один-ко-многим", а если так посмотреть, то доступ к элементам имеют несколько человек. Плюс планирую сделать прослойку для группировки элементов (это будет как-то так: группа пользователей [одна] - группы элементов [много] - элементы [много, но каждый элемент входит только в одну группу])

2. Про курсор хорошее дополнение, спасибо. А edit-save - это что значит?

[Shavadre]

Еще можно сохранение списка повесить на событие "Destroy", например или на его аналог, чтобы базу запросами не грузить. Т.е. при окончании работы сохранение делать. Правда не знаю при аварийном закрытии браузера вызывается ли какое-нибудь событие. Вряд ли :-)

[Denis Morozov]

@Remmi
1. если у вас один ко многим(элемент к пользователям), то это значит что один пользователь может иметь только один элемент, или я что-то не так понял?
2. классичское решение редактирования данных. переходите в edit-мод, редактируете данные, подтврждаете сохранение кнопкой save

[Remmi]

@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

[Denis Morozov]

@Remmi как организуется связь пользователя и элемента: любой пользователь видит все группы элементов? пользователь видит только те группы которые принадлежат его компании? или будет ещё одна связь многи ко многи (пользователи к группам элементов)?

[Remmi]

@morozovdenis пользователь видит только те группы, которые принадлежат его компании.)

[Denis Morozov]

@Remmi тогда 2 варианта:
1. таблица с 4-мя полями (id, user_id, group_id, TEXT order) и в order складывать 1:0;20:1;15:2 - сериализованный dictionary
2. таблица с 4-мя полями (id, user_id, group_id, element_id, int order) и хранить order для каждого элемента отдельной строчкой

[Remmi]

@morozovdenis интересный вариант, в плане того, что разделы получаются настраиваемыми под пользователя конкретного, а не под компанию.

Правильно понимаю, что в 1 варианте нужно контролировать сериализацию и обратный процесс на клиенте, при этом меняться будет N строк, где N - количество групп?

А во втором всё будет проще с контролем, но меняться будет больше строк - M, где M - количество элементов?

[Denis Morozov]

>> интересный вариант, в плане того, что разделы получаются настраиваемыми под пользователя конкретного, а не под компанию.

вам это и нужно если два пользователя из одной и той же компании должны уметь делать разную сортировку для одной и той же группы

>> Правильно понимаю, что в 1 варианте нужно контролировать сериализацию и обратный процесс на клиенте, при этом меняться будет N строк, где N - количество групп?

да. но хранить не нужно сразу для всех групп, надо поставить проверку - если записи для нужной группы элементов нет, то использовать сортировку по умолчанию. в этом случае запись в БД будет создаваться тогда когда пользователь первый раз отсортирует группу

>> А во втором всё будет проще с контролем, но меняться будет больше строк - M, где M - количество элементов?

да, но опять же записи для элементов должны создаваться только когда пользователь первый раз отсортирует

[Remmi]

@morozovdenis спасибо за столь подробные ответы, особенно за идею с сериализацией!

[Denis Morozov]

@Remmi поправка:
сериализацию/десериализацию не обязательно делать на клиенте, можно и на сервере. наверно можно и в самом sql.
в любой случае если будете использовать первый вариант, то позаботьтесь о валидации значений которые там приходят