Реалізація коментарів та сподобань у базі даних

Я розробник програмного забезпечення. Я люблю кодувати, але ненавиджу бази даних ... Зараз я створюю веб-сайт, на якому користувачеві буде дозволено позначати суб'єкт господарювання як сподобався (як у FB), позначити його та прокоментувати .

Я застрягаю в дизайні таблиць баз даних для обробки цієї функціональності. Рішення є тривіальним, якщо ми можемо це зробити лише для одного типу речей (наприклад, фотографій). Але мені потрібно ввімкнути це для 5 різних речей (наразі, але я також припускаю, що ця кількість може зростати, коли зростає вся служба).

Тут я знайшов кілька подібних запитань, але жодне з них не має задоволеної відповіді, тому я задаю це питання ще раз.

Питання полягає в тому, як правильно, ефективно та еластично спроектувати базу даних, щоб вона могла зберігати коментарі до різних таблиць , лайків для різних таблиць та тегів для них. Якась модель дизайну як відповідь буде найкращою;)

Детальний опис : у мене є таблиця User з деякими даними користувачів і ще 3 таблиці : Photoз фотографіями , Articlesзі статтями , Placesз місцями . Я хочу ввімкнути будь-якого зареєстрованого користувача:

• прокоментуйте будь-яку з цих 3 таблиць

• позначте будь-який із них як сподобався

• позначте будь-який із них тегом

• Я також хочу порахувати кількість лайків для кожного елемента та кількість разів, коли цей тег був використаний.
  
  

1- ^й підхід :

а) Для тегів , я створити таблицю Tag [TagId, tagName, tagCounter] , то я буду створювати багато-до-багатьох відносини таблиць для: Photo_has_tags, Place_has_tag, Article_has_tag.

б) Те саме вважається за коментарі.

в) я створю таблицю LikedPhotos [idUser, idPhoto] , LikedArticles[idUser, idArticle], LikedPlace [idUser, idPlace]. Кількість лайків буде розрахована за запитами (що, я вважаю, це погано). І ...

Мені дуже не подобається ця конструкція останньої частини, вона погано пахне для мене;)

2 - ^й підхід :

Я створити таблицю , ElementType [idType, TypeName == some table name]яка буде заповнюватися адміністратором (мене) з іменами таблиць , які можуть бути сподобалися , коментували або помічені . Тоді я буду створювати таблиці :

а) LikedElement [idLike, idUser, idElementType, idLikedElement]те саме для коментарів і тегів із відповідними стовпцями для кожного. Тепер, коли я хочу зробити сподобалось фото, я вставив:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo'
INSERT (user id, typeId, photoId)

і для місць:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Place'
INSERT (user id, typeId, placeId)

і так далі ... Я думаю, що другий підхід кращий, але я також відчуваю, що щось не вистачає і в цій конструкції ...

Нарешті, мені також цікаво, яке найкраще місце для зберігання лічильника, скільки разів сподобався елемент. Я можу думати лише про два способи:

1. в Photo/Article/Placeтаблиці елементів ( )
2. шляхом вибору count ().

Я сподіваюся, що моє пояснення цього питання більш ґрунтовне.

Найбільш розширене рішення - мати лише одну "базову" таблицю (підключену до "лайків", тегів та коментарів) та "успадкувати" всі інші таблиці з неї. Додавання нового типу сутності означає просто додавання нової "успадкованої" таблиці - вона автоматично підключається до цілої машини, як / тег / коментар.

Термін відносин між особами для цього є "категорією" (див. Посібник з методів ERwin , розділ: "Взаємовідносини підтипу"). Символ категорії:

Якщо припустити, що користувачеві можуть подобатися декілька сутностей, один і той же тег може використовуватися для більш ніж однієї сутності, але коментар залежить від сутності, ваша модель може виглядати так:

До речі, існує приблизно 3 способи реалізації "категорії ER":

• Усі типи в одній таблиці.
• Всі типи бетону в окремих таблицях.
• Усі конкретні та абстрактні типи в окремих таблицях.

Якщо у вас немає дуже жорстких вимог до продуктивності, третій підхід, мабуть, найкращий (мається на увазі, що фізичні таблиці відповідають 1: 1 сутностям на діаграмі вище).

Оскільки ви «ненавидите» бази даних, чому ви намагаєтесь їх впровадити? Натомість вимагайте допомоги у того, хто любить та дихає цим матеріалом.

Інакше навчіться любити свою базу даних. Добре розроблена база даних спрощує програмування, інженерію сайту та згладжує його подальшу роботу. Навіть досвідчений дизайнер не може мати повний і ідеальний прогноз: потрібні деякі зміни схеми вниз по дорозі, коли з'являться шаблони використання або змінюються вимоги.

Якщо це індивідуальний проект, запрограмуйте інтерфейс бази даних на прості операції, використовуючи збережені процедури: add_user, update_user, add_comment, add_like, upload_photo, list_comments тощо. Не вкладайте схему в один рядок коду. Таким чином, схему бази даних можна змінити, не впливаючи на будь-який код: про схему повинні знати лише збережені процедури.

Можливо, вам доведеться кілька разів переробляти схему. Це нормально. Не хвилюйтеся про те, що ви вдосконалите його в перший раз. Просто зробіть його досить функціональним для прототипу початкового дизайну. Якщо у вас є розкіш часу, скористайтеся ним, а потім видаліть схему і повторіть це. Це завжди краще вдруге.

Це загальна ідея, будь ласка, не приділяйте багато уваги стилям назв полів, а більше відношенню та структурі

Цей псевдокод отримає всі коментарі до фотографії з ідентифікатором 5
ВИБІР * ВІД дій,
де ДЕРЖАВИ.id_Stuff = 5
AND Actions.typeStuff = "фото"
І actions.typeAction = «коментар»

Цей псевдокод отримає всіх лайків або користувачів, які сподобалися фото з ідентифікатором 5
(ви можете використовувати count (), щоб отримати лише кількість лайків)

SELECT * FROM actions  
WHERE actions.id_Stuff = 5  
AND actions.typeStuff="photo"  
AND actions.typeAction = "like"  

наскільки я розумію. потрібно кілька таблиць. Між ними існує багато відношень.

• Таблиця, в якій зберігаються дані користувача, такі як ім’я, прізвище, дата народження з полем ідентичності.
• Таблиця, в якій зберігаються типи даних. ці типи можуть бути фотографіями, поділками, посиланнями. кожен тип повинен мати унікальну таблицю. тому існує взаємозв'язок між їх окремими таблицями та цією таблицею.
• кожен тип даних має свою таблицю. наприклад, оновлення статусу, фотографії, посилання.
• остання таблиця для багатьох-багатьох стосунків зберігає ідентифікатор, ідентифікатор користувача, тип даних та ідентифікатор даних.

Подивіться на схеми доступу, які вам знадобляться. Чи здається, що будь-який із них зробив особливо складним чи неефективним моє вибір одного дизайну чи іншого?

Якщо не користь тієї, яка потребує меншої кількості таблиць

В цьому випадку:

1. Додати коментар: ви або вибираєте певну таблицю багато / багато, або вставляєте в загальну таблицю з відомим конкретним ідентифікатором для того, що вам подобається, я думаю, що клієнтський код буде трохи простішим у вашому другому випадку.
2. Знайти коментарі до елемента: тут, здається, використовувати загальну таблицю трохи простіше - у нас є лише один запит, параметризований за типом сутності
3. Знайдіть коментарі людини щодо одного виду: простий запит в будь-якому випадку
4. Знайдіть усі коментарі людини щодо всіх речей: це так чи інакше здається.

Я думаю, що ваш "дискримінаційний" підхід, варіант 2, дає простіші запити в деяких випадках, а в інших не здається набагато гіршим, тому я б пішов з ним.

Однозначно перейдіть з другим підходом, де у вас є одна таблиця і зберігається тип елемента для кожного ряду, це дасть вам набагато більше гнучкості. В основному, коли щось логічно можна зробити з меншою кількістю таблиць, майже завжди краще працювати з меншою кількістю таблиць. Однією з переваг, яка мені зараз спадає на думку про ваш конкретний випадок, є те, що ви хочете видалити всі сподобалися елементи певного користувача, при першому підході вам потрібно задати один запит для кожного типу елементів, але з другим підходом це можна зробити. маючи лише один запит або врахуйте, коли ви хочете додати новий тип елемента, при першому підході він передбачає створення нової таблиці для кожного нового типу, але при другому підході ви нічого не повинні робити ...

Розгляньте можливість використання таблиці за суттю для коментарів тощо. Більше таблиць - краща різкість та масштабування. Це не проблема контролювати багато подібних таблиць для всіх моїх фреймів.

Одного разу вам потрібно буде оптимізувати читання з такої структури. Ви можете легко створити аграгуючі таблиці над базовими та трохи втратити на записі.

Одна велика таблиця зі словником може стати некерованою за один день.