- MySQL
- Бази даних
- Збереження даних
- Обробка даних
БД: MySQL.
Завдання: зберігати словаревідние дані у вигляді id: int-> value: string.
Проблема: виявилося, що іноді потрібно, щоб одному id відповідав список значень. При цьому, якщо навіть список складається з одного елемента, все одно потрібно відрізняти його від звичайного значення.
Я бачу кілька варіантів рішення, але жоден мені не подобається.
1) Зберігати дані не у вигляді рядка, а в якомусь форматі: XML, JSON, etc. Тоді в одне строкове поле можна буде зберегти цілий об'єкт.
Варіант не подобається тим, що в результаті отримуємо денормализация даних і проблеми, з нею пов'язані, наприклад, неможливість оперувати значеннями списку окремо стандартними засобами SQL. Читання і зміна окремих елементів прийдеться реалізовувати засобами програми.
1.а) Зберігати дані в одному рядку з роздільником. Це окремий випадок варіанту 1, і мінуси ті ж самі.
2) Створити окрему таблицю для значень списків.
Варіант не подобається тим, що прийдеться робити запити вже до двох таблиць як при читанні, так і під час запису.
3) Зберігати всі дані в одній таблиці, просто не робити id рядка словника унікальним ключем, тоді можна буде додавати кілька записів для одного id.
Не подобається тим, що тоді складно визначити, чи є елемент звичайним елементом, або ж частиною списку. Додавання спеціального поля-прапора а-ля is_list_element - милицю.
Ну як на мене то варіант2 (Створити окрему таблицю для значень списків.) Є оптимальним і стандартним. Зазвичай від нього відходять тільки в нестандартних ситуаціях. Не рекомендую вигадувати велосипед.
Так, швидше за все, доведеться використовувати саме його. Я просто сподівався, що випустив з уваги якийсь очевидний і хороший варіант.
Дозвольте поцікавитися, а як співвідношення звичайних елементів до спискового на щось впливає?
Мене ось турбує інше питання. Я зараз створив дві таблиці за варіантом №2, і у цих таблиць вийшла ідентична структура, за винятком унікального індексу в першій таблиці.
Тобто маємо три поля: id, control_id, value.
У таблиці з простими елементами control_id потрібно, щоб поставити у відповідність запис в цій таблиці і елемент сторінки, в який дані будуть потрапляти (textbox). У другій таблиці control_id виконує ту ж роль для dropdown-листів + по цьому полю потрібно буде групувати записи.
Все добре, але практично ідентична структура таблиць наводить на підозри :)
Дозвольте поцікавитися, а як співвідношення звичайних елементів до спискового на щось впливає? Якщо у Вас всього 1% записів виду «список», і всього 1-2 дубля на кожну, то 99 раз з 100 Ви будете витрачати 2 запити замість одного, і тільки 1 раз заощадите на цьому щось. Чи варто це того?
Це щось схоже на кешуванню. Якщо кеш довго будується ... і у Вас 99% влучень в кеш це добре, а якщо 1% попадання в кеш, то сенсу в кеші в общем-то не багато. З кешем це якось більш очевидно :)
Все добре, але практично ідентична структура таблиць наводить на підозри Саме. Ви тут абсолютно праві.
Але остаточне рішення залежить від Ваших реальних даних. Нормалізація повинна робитися на благо, не в останню чергу для зменшення обсягу даних. А в разі майже повного дублювання ...
Тобто якщо у Вас по 10 в середньому значень на кожен ключ, і при цьому 80% ключів мають значення типу «список», то вибір 2-ої варіанти однозначний. А якщо списки рідкісні і невеликі, то не однозначний як мінімум.
Ваш відповідь на питання