Можно ли использовать такую структуру таблиц?

Question

[WebDev]

Здравствуйте.
В проекте есть таблица posts - это таблица с постами из разных социальных сетей.
В самом начале соц сети было 3 - facebook, twitter, instagram.
Я хотел сделать следующую структуру:

posts:
id, type, created_at

facebook_posts:
id, post_id, name, message, ...

instagram_posts:
id, post_id, image, message, ...

twitter_posts:
id, post_id, name, message, ...

То есть таблицу постов и через внешний ключ посты разных типов, но так как соц сети было всего три, я решил засунуть их в одну таблицу и получилось вот так:

posts:
id, type, fb_name, fb_message, ..., tw_name, tw_message, ..., inst_image, inst_message, ..., created_at

То есть если пост из фейсбука, то все остальные поля просто со значением null.
Со временем требования изменились и теперь соц. сетей не 3, а 14. Поля для каждой новой сети я постепенно добавлял в эту таблицу и теперь их там 80.

Страшно ли это? Какие плюсы/минусы такого подхода?

UPD: Те, кто говорят что нужно разносить по разным таблицам, ответьте пожалуйста на вопрос. Я записываю новые посты сразу пачкой - собираю массив из тысячи постов и делаю один инсёрт. Как такой инсёрт сделать в две таблицы вместо одной?

Answer 1

[Евгений Вольф]

Здравствуйте.
В проекте есть таблица posts - это таблица с постами из разных социальных сетей.

Здравствуйте. С учётом того, что в тегах Вы указали MySQL, подозреваю, что используете Вы именно эту БД... А у этой БД (как и у многих других) есть её характерные особенности. В частности, MySQL довольно быстро обрабатывает таблицы с большим количеством записей (вертикально) и начинает прилично так проседать, когда кол-во столбцов (или того хуже, объём данных в этих столбцах) растёт (горизонтально). Это из личного опыта, и на возведение в статус аксиомы - не претендует

А так же по той причине, на основании следующего:
1. Насколько я понимаю, данные у Вас из разных соц. сетей - по определению разные (в смысле, какая-то их часть), но их фактическое количество (кол-во соц. сетей или источников данных) - фиксированное
1.1 Даже частично одинаковые данные из разных соц. сетей могут иметь разный формат, например пост из твиттера не может быть длинее N символов (не помню сколько... 140?), а пост в ФейсБуке - может быть куда больше... и т.д.
2. При добавлении новой соц. сети - у Вас добавляет не просто какое-то "радомное свойство к товару", типа: "была газовая плита, у нее была ширина и длина, сегодня померили - нужно теперь высоту добавить", с введением новой соц. сети в код приложения добавляется какой-то довольно "толстый" модуль, для обработки конкретно этой соц. сети

С учётом выше сказанного, я бы делал для каждой соц. сети, отдельную таблицу, так как:
1. Кол-во параметров для каждой соц. сети не меняется (или меняется крайне редко)
2. Таким образом одна таблица будет меньше занимать на диске, т.е. в некотором смысле - это будет сегментирование (хоть и в несколько упрощенной и "вынужденной", а не осознанной форме), что в общей сложности повышает производительность
3. Кол-во "дыр" в данных у Вас будет гораздо меньше, а с учётом того, что постов там у Вас тысячи, а соц. сете не 2 и не 3, а уже 14 и это не предел...

P.S.

Как такой инсёрт сделать в две таблицы вместо одной?

Сделать два инсёрта. Если для Вас очень принципиально время вставки и оно гораздо важнее времени получения данных из таблицы (и два инсёрта - гораздо медленнее одного) - используйте соотв. тип табиц, кажется он называется "ARCHIVE" в MySQL.

Как такой инсёрт сделать в две таблицы вместо одной?

Второй вариант - заменить MySQL на PostgreSQL и хорошенько его изучить. Там есть "наследование" таблиц и другие механизмы, которые позволяет Вам делать инсерт в одну таблицу, а движок сам будет распихивать "кого куда", при этом проблема которую Вы описываете изначально, при правильном подходе - будет решена (сама собой) раньше, чем успеет начаться.

Answer 2

[RidgeA]

В начале идея была гораздо разумнее.

Comments

[WebDev]

аргументируйте, пожалуйста

[RidgeA]

добавить новый источник комментариев - изменение текущей таблицы.
При большой таблице это может привести к нехилому стопу всего сервера.
Неудобно использовать, если нужно вытянуть данные по одному источнику.
Много пустых ячеек - в одной строке только малая часть должна быть заполнена, та, которая касается конкрентного источника, остальные - пустые.

Answer 3

[Андрей Саныч]

Вы привели яркий пример того, как денормализация базы ухудшает дальнейшую поддержку. Надо было делать так, как вы написали в начале поста. И тогда расширяемость и поддержка БД шла б как по маслу. Передалайте в нормальную структуру, пока не поздно. Иначе будете себе локти потом грызть

Comments

[WebDev]

Аргументируйте, пожалуйста. И если можно, ответьте вопрос, я обновил.

[Андрей Саныч]

WebDev, аргументирую. Первый аргумент: вы уже сами боитесь того, что делаете. Второй: легче поддерживать много мелких сущностей, чем одну огромную. Представьте, если у вас будет не 14, а 40 соцсетей... Не дай бог, чтобы после вас кто-то поддерживал этот код и базу. Вас найдут и сожгут

Answer 4

[Максим Федоров]

Шо то ху**я, шо это ху**я!

Пост же ИЗ соцсети? Значит у поста есть только 1 соцсеть и только 1 пост?
то есть связь 1 к 1

1. Сделайте обычный `posts` с полями message, image, url и т.д...
и сдеалйте в этой же таблице `posts` поле network

2. Создайте табличку `networks`
В ней храните name, slug (fb, inst, ok ....)