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

Question

[XpeH Петрович]

Старший, скажем так, товарищ по конторе, все время пытается "те данные, которые не сильно нужны, но хранить надо" (которые правда затем могут ипользоваться в тех или иных отчетах), засунуть в сериализованный массив и хранить это как атрибут в SQL. Личнно мне это кажется "говнокодерским" подходом, потому как зачем мы тогда вообще используем РСУБД, можно ж ведь и в файлах хранить. Отсюда вопрос, даже скорее опрос - насколько вы, уважаемые пользователи тостера, считаете это...ммм....нормальным? Поделитесь мыслями
ЗЫ.: Тем пхпшникам, которые думают что раз так можно, то так и нужно, говорю сразу, можете не писать ничего. Если по существу вы понимаете что так именно н у ж н о делать по каким-то причинам, или не нужно - велкам!
ЗЫ2.: Остальная часть БД состоит из порядка 50 таблиц, классифицирована и спроектирована так как по крайней мере говорят люди типа Кодда или Дейта (им же можно верить, правда?)). Поэтому помимо того что я не нахожу хранить данные в такой бд в сериализованном виде, мне также это кажется по крайней мере не эстетчиным
ЗЫ3.: это не Big Data, там порядка 1500 записей (просто по туче полей на каждую запись)

Comments

[Сергей]

Хехе, у меня на работе повсеместно использовался сериализованный PHP-массив.
И вот однажды мне потребовалось преобразовать огромную таблицу из CP-1251 в UTF-8. Вот тут началось веселье)))))

[Виталий Хоменко]

> Тем пхпшникам

А в глаз? )

[XpeH Петрович]

Виталий Хоменко
1. Если Вы относите себя к их числу, то в глаз можете дать себе за то что такие как они распространили свои методологии разработки типа "работает - не трогай -> и хрен с ним" как чуму по всему рунету;
2. Те пхпшники - это те которых я описал в пункте 1, я знаю и тех пхпшников которые пишут нормально, не используя магию, которая актуальна в пхп и только и стараются написать "чистый" код;
3. Я и сам пишу на пхп но не отношу себя к их числу;
4. Мы с Вами уже перешли на неформальный стиль общения?;
5. Если это угроза, то давайте в личном порядке, и я ВСЕ Вам объсяню (ну раз уж пошла такая пьянка);
6. Если с чем-то несогласны - аргументируйте, за Вашей эмоциональной оценкой я сюда не ходил, а если есть что по существу - давайте обсудим, думаю всем здесь присутствующим было бы приятно вести конструктивную беседу.

[Виталий Хоменко]

XpeH Петрович: Ой-йой, кого не спроси, так все не относятся к их числу ) Ну просто какая-то невидимая армия криворуких программистов, как суслики. Никто их не видит, а они все пишут и пишут.

1. Я должен дать себе в глаз за то, что кто-то плохо пишет? С таким же успехом вы себе дайте в глаз за результат работы вашего "товарища по конторе" и всех остальных, кто плохо пишет.
2. Могут писать криво все. Но почему-то вы указали только пхпшников. Так это расизм! )
3. Не спорю даже с вами.
4. Нет блин, сейчас одену галстук и буду писать вам заверенные письма через юридический отдел.
5. Все-все, не надо больше! Я же пошутил)
6. У меня нет желания вам ничего доказывать.

Это была шутка, смайлик в конце видите? Нет? Так он там есть, это вам говорит один из "тех самых пхпешников" )

[XpeH Петрович]

Виталий Хоменко ладно, ладно, сорри, я порой чрезмерно серъезен) а про 3 пункт - просто пхп реально позволяет многое из того что позволять нормальный язык не должен, отсюда и некая...расхлябанность.

Answer 1

[XpeH Петрович]

абсолютно по-быдлокодерски. неструктурированные данные сваливать в NoSQL и иже с ними, чтоб потом устраивать по ним Data Mining. Или нормализовать сразу, что представляется менее возможным с учетом стандартных сроков разработки.

Answer 2

[Ришат Кадыров]

В идеальном мире, где пони какают бабочками, так делать конечно нельзя.
В нашем мире, такое есть, к примеру, в Wordpress - самой популярной CMS в мире.
Разумеется, у вордпресса весьма уродливый код, но это не мешает им быть сверхуспешными.

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

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

Comments

[XpeH Петрович]

Ришат Кадыров достойный ответ, и я Вас прекрасно понимаю...но как же быть, если важна целостность данных? без реляций я не смогу ее контролировать. (в этом плане например и Mongo иногда проигрывает Sql)

[trevoga_su]

XpeH Петрович: > .но как же быть, если важна целостность данных?
Подход сериализации нужен тогда, когда не надо хранить эту самую целостность данных.

В конце-концов, в постгресе есть hash тип данных (не помню как он точно называется) и ничего, работает на ура.

[Ришат Кадыров]

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

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

Но если я ошибся, и вы спроектировали архитектуру уже десятка подобных БД, и для вас все абсолютно прозрачно и понятно, то вполне можно оставить все как есть, но это вы и без меня должны знать)

А по поводу целостности данных... На крайний случай над SQL у вас наверняка уже есть пара слоев абстракции, которые могут дешево гарантировать целостность. Если возможности дешево гарантировать целостность нет - к примеру нужны внешние ключи, то сериализировать ничего нельзя.

[XpeH Петрович]

Ришат Кадыров да, вы права, куча теории, но мало той практики которая учит)

[XpeH Петрович]

Ришат Кадыров простите, только сейчас опечатку увидел... "правы" конечно же)

Answer 3

[Станислав Макаров]

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

Comments

[XpeH Петрович]

Станислав Макаров Вы более чем правы, но мы с Вами прекрасно понимаем что заказчик, или тот кто "сверху", очень часто не учитывает что будет потом - в моем случае основная часть ТЗ прописывается как ни странно мной (причем в основном процентов на 70), а как только пытаюсь доказать этому "сверху" что лучше вложиться сейчас и сделать хорошо (даже если этой необходимости не возникнет) на всякий случай, он отвечает "сделай сейчас на коленке, "нужную" часть БД нормализуй как надо, а это сбрось в сериализованный массив"(авось не пригодится). Отсюда у меня такое беспокойство по поводу хранения этой инфы. Ну и да, там не конфиг пользователя, но даже несмотря на то что информация является многомерным массивом - он не настолько многомерен и разнороден чтобы нельзя его было нормализовать. Плюс сроки. Нормализовать совсем до чертиков конечно я не собирался, атомарность более чем представляю.

Answer 4

[trevoga_su]

Все зависит от задачи. Пример - конфиг пользователя. Смысла хранить его в реляционной структуре практически нет. Никто не будет по этому конфигу делать какую-то статистику или поиск. Добавление нового свойства для конфига - сделать чекбокс в шаблоне, образно говоря. Одним запросом вытащили сериализацию, получили масив с параметрами .. PROFIT!

Answer 5

[Александр]

Почему бы просто не нормализовать БД, что бы избавиться от массивом? Ну или как вариант, в постгрес есть тип данных для хранения json объектов, по которым можно производить поиск. Если данные не имеют фиксированной структуры, то почему бы их не хранить в файлай или использовать, что нибудь типа mongodb.

Comments

[XpeH Петрович]

фишка в том что данные таки нормализованы. но они типа "не сильно нужны" а хранить надо, поэтому старший товарищ придумал "гениальное" решение описанное выше) MongoDB уже рассматривал, буду на нее переезжать, ибо удобнее. и движок БД у нас к сожалению MySQL, с PostgreSQL работал мало, чтобы использовать ее на всю катушку (хотя на нее тоже можно переехать)

[Александр]

Ну если нет необходимости поиска по этим данным, то почему бы и нет. Только все же не плохо учесть размер сериализованных данный, как вариант можно использовать BLOB, если они не хранятся в строке, а в бинарном виде.

[XpeH Петрович]

Александр необходимости де факто нет, но потенциальная возможность в будущем есть. и опять же, к вопросу о проектировании - не должен ли я как проектировщик БД (в данном конкретном случае) учесть такую возможность в будущем?

[Александр]

Ну тогда можно сделать следующим образов: есть таблица полей, есть таблица значений полей. Таблица значений полей связана по внешнему ключу с таблицей, в которой у вас БЫЛИ сериализованные данные. При добавлении в бд нового массива, вставляются ранее не известные ключи в таблицу полей и значений по этим ключам в таблицу значений. Выборку желательно реализовать по WHERE KEY IN (...), что бы избежать джоинов.

Answer 6

[Владимир Голубев]

Такое чисто теоретически допустимо только если верно одно или оба из следующих утверждений:
1) Эти данные совершенно не систематизированы, неизвестно что может понадобиться сохранить в следующий раз, сколько будет параметров, какого они будут формата и т.д.
2) По этим данным никогда не потребуется проводить сложный поиск.

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

Comments

[Adamos]

3) критична ли скорость этого поиска. Если нет, то стоит хранить как можно проще, без систематизации, с которой хрен угадаешь, подойдет она под будущие нужды или нет.

Answer 7

[BatteryLow]

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

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

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

Comments

[Владимир Голубев]

Я работал над проектом, где была адресная база, и координаты по широте и долготе хранились отдельно, как и такие данные как номер дома, название улицы, город и т.д. В сумме это были три таблицы - города, улицы\объекты, дома. казалось бы, зачем хранить координаты в разных полях - это же абсолютно связанные величины? Но когда я реализовывал поиск ближайших объектов - мне это понадобилось) При проектировании таблицы всегда лучше предусмотреть дальнейшее развитие...

[BatteryLow]

wladyspb: Да, в вашей ситуации это правильно, поэтому я и акцентировал внимание на том, что решение нужно принимать в зависимости от проекта, если координаты по определению должны быть приватными и поиск по ним не то что не нужен, а даже вреден, то разбивать их нет смысла и именно для этого нужен тим лид который смотрит в будущее.

[XpeH Петрович]

Владимир Голубев Самое интересное что у меня проект и адресную базу включает (но слава Богу без координат, хотя я их буду сам прикручивать). Насчет того что координаты неотделимы друг от друга - не соглашусь с философской точки зрения. На примере декартовой системы - да, у вас есть и x и y, но это ведь все же разные сущности, пусть они и взаимосвязаны и друг без друга не должны (по идее) существовать. Плюс не стоит забывать - если они связаны (а связи это и есть relation, простите за тавтологию), то наличие двух полей под например ширину и долготу в таблице coordinates и является свидетельством того что эти величины взаимосвязаны и друг без друга не могут.
грубо говоря, таблица - org_id, "ширина", "долгота" (не помню как переводится), все поля NOT_NULL, PRIMARY_KEY составной из этих трех полей...куда Вам еще больше гарантировать что они, координаты, связаны между собой?)
BatteryLow а почему приватность нельзя обеспечить правами доступа а не...мммм....слегка каверкая архитектуру?

[BatteryLow]

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

[Владимир Голубев]

BatteryLow: Если latitude и longitude это поля одной таблицы - при чём тут джойны? Я понял вашу мысль, но она совсем не для этого примера)

[BatteryLow]

Владимир Голубев: Да, естественно это одна таблица, я к тому, что это еще один джойн, а потом еще один на например расписание работы - время это тоже отдельная сущность (а то и две), а потом еще и еще для других параметров, пока запрос на выборку 10 карточек не начинает длится пару секунд. И все же это абстрактный пример, я его привел для того что бы было более полное понимание возможных ситуаций и не утверждаю что координаты нужно всегда хранить сериализованными.

Answer 8

[Владимир]

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

В итоге пришлось переделывать.

Comments

[Adamos]

Ну, сериализовать одномерный массив - вообще не вариант. Сразу напрашивается простейшая таблица под него.
А тут, как я понимаю, речь об ассоциативном (возможно, многоуровневом). Который раскладывается только в комплекс таблиц.

[XpeH Петрович]

Adamos именно

Answer 9

[Viktor Koltcov]

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

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

PS Мне кажется, что хорошая ORM будет решением любой проблемы при которой хочется хранить сериализованные объекты, или на PHP таких нет?

Comments

[XpeH Петрович]

насчет того как ORM (Doctrine например, хотя если честно я не знаю других для PHP) работает именно с сериализованными данными в ячейках БД - не знаю. Если же хранить объекты в JSON - зачем мне SQL, я возьму Mongo))) Данные структурированы и не разнородны, плюс важна достоверность информации, как я и говорил в одном из комментариев (они все время меняются местами, не могу сказать выше или ниже))).

[Viktor Koltcov]

XpeH Петрович: Я имел ввиду что ORM сможет за тебя записать в базу массив и считать вернув массив, и при этом все разложить по отдельным полям.

[XpeH Петрович]

Viktor Koltcov да, об этом я не подумал. спасибо, надо попробовать). просто методика занесения данных в данном случае не сильно влияет на структуру их хранения в бд, к сожалению

[Viktor Koltcov]

Василий: Конечно лучше сиреализованный массив в базу пихать...

Answer 10

[Oskaria]

Есть в таком методе определенные плюсы, но их не много. Сразу в голову приходит только один, сомнительный, но всё же.
Один из моих проектов (на php, о да) работает сразу на нескольких языках - русский, английский, украинский и немецкий. На веб части есть лента новостей, обычно несколько строк (мол сегодня был апдейт, приносим извинения за тормоза) и что бы не создавать по столбцу или таблице для каждого языка - я храню сериализованный массив с 4 элементами - каждый элемент = текст новости на своем языке.
Не буду спорить, насколько это верно, но считаю, что это удобно.

Comments

[Adamos]

И поиск по новостям занимает в 4 раза больше времени, не говоря уже о ложных срабатываниях, когда слово на английском есть в немецком?

[Oskaria]

Adamos: поиска по новостям у нас нет)

Answer 11

[raiboon]

Почему все не видят ничего стращного?

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

Comments

[XpeH Петрович]

raiboon это тоже меня отпугивает. насколько понял из своего небольшого опыта, костыли имеют свойство как снежный ком обрастать другими костылями...в конце концов чистенький опрятненький проект в начале превращается в полное несопровождаемое дерьмо в конце, причем конкретно в моем случае - либо из-за долбо**изма типа "я начальник я и спроектирую, а ты подчиняйся" или из-за недосмотра архитектора, если все таки он решил послать PM'а подальше с его нелепыми подходами, и воспользовался нелепым подходом сам. Типичный кстати пример - сам язык PHP. Недавно использовал array_search() и in_array(), что-то надо было поискать в массиве, но мне надо было знать ГДЕ оно, а не есть ли оно там в принципе...потом оказалось что есть баг пятилетней давности, мол, пхп не ищет array_search(0, [массив])

the recursive function by tony have a small bug. it failes when a key is 0

ЗЫ.: примерно по такому же принципу они ввели префикс array_ во всех функциях работы с массивами, если помните - потому что у них кончилось пространство имен, а менять как надо уже неззя, потому что обратная совместимость.
ЗЫ2.: это конечно немного не по теме, просто крик души вырвался)

Answer 12

[Сергей]

Подход имеет место быть когда вы имеете неструктурированные данные.
Минусом данного подхода будет лишь то, что вы не сможете нормально использовать сериализованные данные в запросах + необходимо учесть изменение структуры записываемых данных со временем (т.е. ваша программа должна уметь работать со всеми версиями данных, которые хранятся в бд).