Задать вопрос

Насколько «быдлокодерским» подходом является хранение сериализованных массивов в SQL?

Старший, скажем так, товарищ по конторе, все время пытается "те данные, которые не сильно нужны, но хранить надо" (которые правда затем могут ипользоваться в тех или иных отчетах), засунуть в сериализованный массив и хранить это как атрибут в SQL. Личнно мне это кажется "говнокодерским" подходом, потому как зачем мы тогда вообще используем РСУБД, можно ж ведь и в файлах хранить. Отсюда вопрос, даже скорее опрос - насколько вы, уважаемые пользователи тостера, считаете это...ммм....нормальным? Поделитесь мыслями
ЗЫ.: Тем пхпшникам, которые думают что раз так можно, то так и нужно, говорю сразу, можете не писать ничего. Если по существу вы понимаете что так именно н у ж н о делать по каким-то причинам, или не нужно - велкам!
ЗЫ2.: Остальная часть БД состоит из порядка 50 таблиц, классифицирована и спроектирована так как по крайней мере говорят люди типа Кодда или Дейта (им же можно верить, правда?)). Поэтому помимо того что я не нахожу хранить данные в такой бд в сериализованном виде, мне также это кажется по крайней мере не эстетчиным
ЗЫ3.: это не Big Data, там порядка 1500 записей (просто по туче полей на каждую запись)
  • Вопрос задан
  • 7636 просмотров
Подписаться 7 Оценить 5 комментариев
Решения вопроса 1
uakoB
@uakoB Автор вопроса
абсолютно по-быдлокодерски. неструктурированные данные сваливать в NoSQL и иже с ними, чтоб потом устраивать по ним Data Mining. Или нормализовать сразу, что представляется менее возможным с учетом стандартных сроков разработки.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 11
laska
@laska
PHP/JS разработчик
В идеальном мире, где пони какают бабочками, так делать конечно нельзя.
В нашем мире, такое есть, к примеру, в Wordpress - самой популярной CMS в мире.
Разумеется, у вордпресса весьма уродливый код, но это не мешает им быть сверхуспешными.

Давайте по чесноку. Нормализированная таблица это круто, но зачастую очень дорого. Кинуть данные сериализированного массива в ячейку и потом ее достать - 10 минут работы программиста.
Проектировать хорошую БД - на порядки сложнее (и требует программистов более высокой квалификации).
И самое печальное, второй вариант на 1500 записей не нужен. Можно и в файлах хранить, в общем то. Но с БД будет несколько прикольных фич из коробки. Если хранить в файлах, нужно писать ORDER или SELECT самим, что занимает некоторое время.

Поэтому, с точки зрения бизнеса, подход "и так сойдет" более выгоден по деньгам, хоть и оскорбляет ваше чувство прекрасного.
Ответ написан
Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.
Ответ написан
trevoga_su
@trevoga_su
Все зависит от задачи. Пример - конфиг пользователя. Смысла хранить его в реляционной структуре практически нет. Никто не будет по этому конфигу делать какую-то статистику или поиск. Добавление нового свойства для конфига - сделать чекбокс в шаблоне, образно говоря. Одним запросом вытащили сериализацию, получили масив с параметрами .. PROFIT!
Ответ написан
Комментировать
Почему бы просто не нормализовать БД, что бы избавиться от массивом? Ну или как вариант, в постгрес есть тип данных для хранения json объектов, по которым можно производить поиск. Если данные не имеют фиксированной структуры, то почему бы их не хранить в файлай или использовать, что нибудь типа mongodb.
Ответ написан
wladyspb
@wladyspb
Программист
Такое чисто теоретически допустимо только если верно одно или оба из следующих утверждений:
1) Эти данные совершенно не систематизированы, неизвестно что может понадобиться сохранить в следующий раз, сколько будет параметров, какого они будут формата и т.д.
2) По этим данным никогда не потребуется проводить сложный поиск.

При этом, возникает вопрос - а нафига вообще такие данные пихать в таблицу SQL?
Логи на мой взгляд более целесообразно хранить в файле.
Если это какие-то сложные пользовательские данные - ну заведите вы под них отдельную таблицу, добавляя поля по мере надобности.
Если это полностью неструктурированные данные - стоит подумать о документарной БД.
Ответ написан
@BatteryLow
Ситуация не простая, по хорошему лучше не прибегать к такому методу хранения, он все же считается уязвимостью архитектуры и в подавляющем большинстве случаев лучше нормализовывать базу. Но у каждого разработчика в практике случается ситуация когда встает выбор, в действительно ли это нужно, и этот выбор нужно делать вдумчиво и исходя из особенностей проекта и возможно сериализация окажется вполне правильным решением.

Приведу пример - в карточке организации есть параметр положение на карте, он описывается несколькими характеристиками: координаты точки, координаты 2х противоположных углов карты и маштабом карты, нужно ли их хранить в отдельных полях таблицы когда они неотделимы друг от друга, я считаю что абсолютно нет.

Но в вашей ситуации все может быть по другому, тут нужен опытный тим лид который может предусмотреть возможные проблемы в будущем конкретно для этого проекта принять решение, запретить или разрешить такое хранение.
Ответ написан
azrail_dev
@azrail_dev
Достался проект, в котором некоторая часть данных хранилась в виде сериализованных массивов.
Хранились списки е-mail, привязаные к городам. В каждом массиве - около десятка адресов.
Проблемы, c которыми столкнулись:
1. Поиск и вывод в других системах
2. Быстренько что-то поправить - не спорю, не правильно, но иногда ситуация требует этого.
3. Сбор статистики.

В итоге пришлось переделывать.
Ответ написан
Vityarik
@Vityarik
Сириализация 100% принесет проблемы, если хранить объекты в 1 поле то лучше JSON / XML

Что вы (точнее они) хотите сэкономить, используя такой подход?

PS Мне кажется, что хорошая ORM будет решением любой проблемы при которой хочется хранить сериализованные объекты, или на PHP таких нет?
Ответ написан
@Oskaria
Есть в таком методе определенные плюсы, но их не много. Сразу в голову приходит только один, сомнительный, но всё же.
Один из моих проектов (на php, о да) работает сразу на нескольких языках - русский, английский, украинский и немецкий. На веб части есть лента новостей, обычно несколько строк (мол сегодня был апдейт, приносим извинения за тормоза) и что бы не создавать по столбцу или таблице для каждого языка - я храню сериализованный массив с 4 элементами - каждый элемент = текст новости на своем языке.
Не буду спорить, насколько это верно, но считаю, что это удобно.
Ответ написан
@raiboon
Почему все не видят ничего стращного?

Это отвратный подход. Это сегодня не нужно их выбирать, а завтра нужно. И, к тому же, это дольше - больше костылей будет, написать еще одну модельку быстрее, чем каждый раз помнить об этом костыле.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Подход имеет место быть когда вы имеете неструктурированные данные.
Минусом данного подхода будет лишь то, что вы не сможете нормально использовать сериализованные данные в запросах + необходимо учесть изменение структуры записываемых данных со временем (т.е. ваша программа должна уметь работать со всеми версиями данных, которые хранятся в бд).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы