Насколько «быдлокодерским» подходом является хранение сериализованных массивов в SQL?
Старший, скажем так, товарищ по конторе, все время пытается "те данные, которые не сильно нужны, но хранить надо" (которые правда затем могут ипользоваться в тех или иных отчетах), засунуть в сериализованный массив и хранить это как атрибут в SQL. Личнно мне это кажется "говнокодерским" подходом, потому как зачем мы тогда вообще используем РСУБД, можно ж ведь и в файлах хранить. Отсюда вопрос, даже скорее опрос - насколько вы, уважаемые пользователи тостера, считаете это...ммм....нормальным? Поделитесь мыслями
ЗЫ.: Тем пхпшникам, которые думают что раз так можно, то так и нужно, говорю сразу, можете не писать ничего. Если по существу вы понимаете что так именно н у ж н о делать по каким-то причинам, или не нужно - велкам!
ЗЫ2.: Остальная часть БД состоит из порядка 50 таблиц, классифицирована и спроектирована так как по крайней мере говорят люди типа Кодда или Дейта (им же можно верить, правда?)). Поэтому помимо того что я не нахожу хранить данные в такой бд в сериализованном виде, мне также это кажется по крайней мере не эстетчиным
ЗЫ3.: это не Big Data, там порядка 1500 записей (просто по туче полей на каждую запись)
Хехе, у меня на работе повсеместно использовался сериализованный PHP-массив.
И вот однажды мне потребовалось преобразовать огромную таблицу из CP-1251 в UTF-8. Вот тут началось веселье)))))
Виталий Хоменко
1. Если Вы относите себя к их числу, то в глаз можете дать себе за то что такие как они распространили свои методологии разработки типа "работает - не трогай -> и хрен с ним" как чуму по всему рунету;
2. Те пхпшники - это те которых я описал в пункте 1, я знаю и тех пхпшников которые пишут нормально, не используя магию, которая актуальна в пхп и только и стараются написать "чистый" код;
3. Я и сам пишу на пхп но не отношу себя к их числу;
4. Мы с Вами уже перешли на неформальный стиль общения?;
5. Если это угроза, то давайте в личном порядке, и я ВСЕ Вам объсяню (ну раз уж пошла такая пьянка);
6. Если с чем-то несогласны - аргументируйте, за Вашей эмоциональной оценкой я сюда не ходил, а если есть что по существу - давайте обсудим, думаю всем здесь присутствующим было бы приятно вести конструктивную беседу.
XpeH Петрович: Ой-йой, кого не спроси, так все не относятся к их числу ) Ну просто какая-то невидимая армия криворуких программистов, как суслики. Никто их не видит, а они все пишут и пишут.
1. Я должен дать себе в глаз за то, что кто-то плохо пишет? С таким же успехом вы себе дайте в глаз за результат работы вашего "товарища по конторе" и всех остальных, кто плохо пишет.
2. Могут писать криво все. Но почему-то вы указали только пхпшников. Так это расизм! )
3. Не спорю даже с вами.
4. Нет блин, сейчас одену галстук и буду писать вам заверенные письма через юридический отдел.
5. Все-все, не надо больше! Я же пошутил)
6. У меня нет желания вам ничего доказывать.
Это была шутка, смайлик в конце видите? Нет? Так он там есть, это вам говорит один из "тех самых пхпешников" )
Виталий Хоменко ладно, ладно, сорри, я порой чрезмерно серъезен) а про 3 пункт - просто пхп реально позволяет многое из того что позволять нормальный язык не должен, отсюда и некая...расхлябанность.
Ситуация не простая, по хорошему лучше не прибегать к такому методу хранения, он все же считается уязвимостью архитектуры и в подавляющем большинстве случаев лучше нормализовывать базу. Но у каждого разработчика в практике случается ситуация когда встает выбор, в действительно ли это нужно, и этот выбор нужно делать вдумчиво и исходя из особенностей проекта и возможно сериализация окажется вполне правильным решением.
Приведу пример - в карточке организации есть параметр положение на карте, он описывается несколькими характеристиками: координаты точки, координаты 2х противоположных углов карты и маштабом карты, нужно ли их хранить в отдельных полях таблицы когда они неотделимы друг от друга, я считаю что абсолютно нет.
Но в вашей ситуации все может быть по другому, тут нужен опытный тим лид который может предусмотреть возможные проблемы в будущем конкретно для этого проекта принять решение, запретить или разрешить такое хранение.
Я работал над проектом, где была адресная база, и координаты по широте и долготе хранились отдельно, как и такие данные как номер дома, название улицы, город и т.д. В сумме это были три таблицы - города, улицы\объекты, дома. казалось бы, зачем хранить координаты в разных полях - это же абсолютно связанные величины? Но когда я реализовывал поиск ближайших объектов - мне это понадобилось) При проектировании таблицы всегда лучше предусмотреть дальнейшее развитие...
wladyspb: Да, в вашей ситуации это правильно, поэтому я и акцентировал внимание на том, что решение нужно принимать в зависимости от проекта, если координаты по определению должны быть приватными и поиск по ним не то что не нужен, а даже вреден, то разбивать их нет смысла и именно для этого нужен тим лид который смотрит в будущее.
Владимир Голубев Самое интересное что у меня проект и адресную базу включает (но слава Богу без координат, хотя я их буду сам прикручивать). Насчет того что координаты неотделимы друг от друга - не соглашусь с философской точки зрения. На примере декартовой системы - да, у вас есть и x и y, но это ведь все же разные сущности, пусть они и взаимосвязаны и друг без друга не должны (по идее) существовать. Плюс не стоит забывать - если они связаны (а связи это и есть relation, простите за тавтологию), то наличие двух полей под например ширину и долготу в таблице coordinates и является свидетельством того что эти величины взаимосвязаны и друг без друга не могут.
грубо говоря, таблица - org_id, "ширина", "долгота" (не помню как переводится), все поля NOT_NULL, PRIMARY_KEY составной из этих трех полей...куда Вам еще больше гарантировать что они, координаты, связаны между собой?) BatteryLow а почему приватность нельзя обеспечить правами доступа а не...мммм....слегка каверкая архитектуру?
XpeH Петрович: В большом проекте помимо всего еще возникают такие аспекты как трудозатраты и расстановка приоритетов, и реализовывать избыточный функционал становится неразумно. Можно конечно на каждый чих создавать таблицы, связывать их друг с другом, но когда координаты точки это всего лишь малая доля параметров и причем далеко не первостепенная и их можно объединить то ничего в этом зазорного нет, иначе запросы будут состоять из десятка джойнов утягивая ресурсы сервера к ебеням и съедая время рабочее время на их поддержку, оптимизацию и тд.
Владимир Голубев: Да, естественно это одна таблица, я к тому, что это еще один джойн, а потом еще один на например расписание работы - время это тоже отдельная сущность (а то и две), а потом еще и еще для других параметров, пока запрос на выборку 10 карточек не начинает длится пару секунд. И все же это абстрактный пример, я его привел для того что бы было более полное понимание возможных ситуаций и не утверждаю что координаты нужно всегда хранить сериализованными.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
