А для чого ще, по-твоєму, потрібно позбутися від read only статусу на Хабре?
Суть проблеми така:
В даний момент дописую інтернет магазин (комп'ютери, комплектуючі, портативні комп'ютери і тд).
До питання продумування структури бази підійшов не зовсім грунтовно, тому що це перший більш ні менш великий проект.
На початковому етапі, поки в базу додавалися одні ноутбуки, нетбуки і тд, здавалося б, все нормально. Але от далі постало питання про додавання комплектуючих та й подібних товарів, тому що у ноутбуків і їм подібним кількість атрибутів (полів в таблиці)
24 + у кожного виду комплектуючих ще по 5-6 унікальних для кожного виду аттрибутов, тобто в процесі таблиця повинна рости в ширину, ніби й терпимо, але:
У пошуках вирішення проблеми я відправився в інтернети. Ну і власне для себе виділив два основних способи побудови бази:
1) Single Table Inheritance (STI) - дана структура передбачає собою ОДНУ таблицю для всіх товарів всіх видів і, як я і припускав, вона буде рости в ширину і більшість полів в ній буде NULL-евимі. Начебто і кількість товарів не повинна перевищувати 5-6 тисяч (за попередніми прогнозами) тобто таблиця з приблизно 40-50 полями і 5000-6000 рядками без проблем буде повертати потрібні значення в лічені миті. І таки да, така структура є реляційної БД, що для мене особисто було одкровенням.
Тут в "адмінки" при додаванні товару в велику таблицю я просто вказую які поля заповнювати, інші автоматом стають NULL.
2) Entity-Attribute-Value (EAV) - передбачає собою розбиття товарів на три таблиці:
- Entity - Таблиця, де зберігається інфо про ВСІХ товари, але в вигляді 4-5 основних стовпців (однакових для всіх). Таких як: id, Навані, ціна, виробник і тд.
-Attribute- зберігає в собі весь список атрибутів для кожного виду товару в вигляді (id_attribute, attr_value) тобто виходить досить таки довга таблиця, як я зрозумів. Якщо, припустимо, буде тисячі ноутбуків по 15 унікальних параметрів - це 15000 рядків (не так вже й багато, але що є то є)
-Value- таблиця, яка пов'язує Entity і Attribute зовнішніми ключами, пари виду (id_product, id_attribute) тобто розмір її буде трохи більше таблиці Attribute.
Разом: ми маємо розкладену по поличках інформацію про товар, що зберігається "тупо" індексами в базі. Але, знову ж таки, начитавшись в тирнета виділив для себе наступні мінуси цієї структури:
-Запити будуть ДУЖЕ (як на мене) великі. Щоб вивести картку товару потрібно буде нехило натякають INNER JOINов
-Складність структури, а в слідстві і плутанина виникає за частиною движка (нім пишу на PHP), знову все переробляти і тд.
-І взагалі: чи варта гра свічок. При такій кількості товарів чи варто перекручуватися таким чином?
Ось власне що я хотів сказати і що запитати у умів програмування)
Дякую за увагу!
Другий варіант цілком робочий і зручний в роботі, головне правильно розкласти структуру об'єктів і їх властивостей з урахуванням всього спектру товарів так, щоб додавання нових типів товарів не вело до зміни структури бази.
Якщо все зробити правильно, то залишиться тільки стежити за наповненням, якістю і актуальністю даних.
Спасибі за те, що відгукнувся!
На даний момент я намагаюся реалізувати щось на зразок:
Є таблиця з видами основних характеристик: types (id, title)
є таблиця, де зберігаються значення цих характеристик: type_list (id, id_type, value)
і в таблиці товарів (так, вона буде одна для всіх) у поля цих характеристик будуть вноситися зовнішні ключі з таблиці type_list
Інвайт на habrahabr
Щоб краще зрозуміти що тобі в результаті потрібно отримати, можна подивитися на цей функціонал з позиції користувача системи. Уяви робочу вебформу (або підглянуті в іншому магазині) з якої буде йти запит, подивися які фільтри є ключовими, відсікають великі масиви даних виходячи з різного типу товарів (вони і будуть йти окремими довідниками типів або полями).
З'ясуй якого роду взагалі запити можуть бути з кожної форми (від виведення списку товарів з різними полями, до якої-небудь друку-).
Структура цілком логічна, якщо я правильно зрозумів, що це щось типу:
2 | 1 | Комплектуючі - для ремонту і т.п.
3 | 1 | аксесуари
4 | 2 | Нетбуки
5 | 2 | комплектуючі
Хід думок у тебе вірний, але важливо уявити реально працюючий бізнес-процес, це відкриє безліч нюансів і залізних вимог, які краще враховувати відразу, щоб потім не перелопачувати всю структуру і наповнення.
За конкретної реалізації мало чим можу допомогти, тому що не знаю деталей і я не спец в SQL, а просто працюю з базами різних систем, і бачив всяке.
Просто вже 2 дня засинаю і прокидаюся з цими думками в голові)
сиджу на роботі, ось сегондя ввечері вже буду починати щось робити. поки що зупинився на "проапгрейденом" предіущем варіанті:
1 таблиця - goods (id, title, brand, price, img ..) зберігає в собі інфо про ВСІХ товари, але тільки основні поля, які є у кожного товару.
2 таблиця - notebooks (id, id_good, param1, param2, param3) зберігає в собі інфо про ноутбуках, для каждоя ноута - один рядок з id_good - зовнішнім ключем таблиці goods;
Мабуть - це максимум, який я на даний момент зможу з себе вичавити) тому мені до проф. програміста ще далеко, та й терміни підтискають. а ще на мені висить РНР реалізація, админка магазину з широким функціоналом, дизайн сайту, та інші смачні ляпаси типу фільтра товарів як на розетці і тд)