Віталій Хоменко
1. Якщо Ви відносите себе до їх числа, то в око можете дати собі за те що такі як вони поширили свої методології розробки типу "працює - не чіпай -> і хрін з ним" як чуму по всьому рунету;
2. Ті пхпшнікі - це ті яких я описав в пункті 1, я знаю і тих пхпшніков які пишуть нормально, не використовуючи магію, яка актуальна в пхп і тільки і намагаються написати "чистий" код;
3. Я і сам пишу на пхп але не відношу себе до їх числа;
4. Ми з Вами вже перейшли на неформальний стиль спілкування ?;
5. Якщо це загроза, то давайте в індивідуальному порядку, і я ВСЕ Вам об'сяню (ну якщо вже пішла така п'янка);
6. Якщо з чимось незгодні - аргументуйте, за Вашої емоційної оцінкою я сюди не ходив, а якщо є що по суті - давайте обговоримо, думаю всім тут присутнім було б приємно вести конструктивну бесіду.
XpeH Петрович. Ой-йой, кого не спитай, так все не відносяться до їх числа) Ну просто якась невидима армія криворуких програмістів, як ховрахи. Ніхто їх не бачить, а вони все пишуть і пишуть.
1. Я повинен дати собі в око за те, що хтось погано пише? З таким же успіхом ви собі дайте в око за результат роботи вашого "товариша по конторі" і всіх інших, хто погано пише.
2. Чи можуть писати криво все. Але чомусь ви вказали тільки пхпшніков. Так це расизм! )
3. Не сперечаюся навіть з вами.
4. Немає млинець, зараз одягну краватку і буду писати вам завірені листи через юридичний відділ.
5. Все-все, не треба більше! Я ж пожартував)
6. У мене немає бажання вам нічого доводити.
Станіслав Макаров Ви більш ніж праві, але ми з Вами прекрасно розуміємо що замовник, або той хто "зверху", дуже часто не враховує що буде потім - в моєму випадку основна частина ТЗ прописується як не дивно мною (причому в основному відсотків на 70) , а як тільки намагаюся довести цьому "зверху" що краще вкластися зараз і зробити добре (навіть якщо цієї необхідності не виникне) на всякий випадок, він відповідає "зроби зараз на коліні," потрібну "частина БД нормалізуй як треба, а це скинь в серіалізовані масив "(авось не знадобиться). Звідси у мене таке занепокоєння з приводу зберігання цієї інформації. Ну і так, там не конфиг користувача, але навіть незважаючи на те що інформація є багатовимірним масивом - він не настільки багатовимірний і різнорідний щоб можна його було нормалізувати. Плюс терміни. Нормалізувати зовсім до чортиків звичайно я не збирався, атомарность більш ніж уявляю.
Все залежить від завдання. Приклад - конфиг користувача. Сенсу зберігати його в реляційної структурі практично немає. Ніхто не буде з цього конфігу робити якусь статистику чи пошук. Додавання нового властивості для конфіга - зробити чекбокс в шаблоні, образно кажучи. Одним запитом витягли сериализацию, отримали масив з параметрами. PROFIT!
фішка в тому що дані таки нормалізовані. але вони типу "не сильно потрібні" а зберігати треба, тому старший товариш придумав "геніальне" рішення описане вище) MongoDB вже розглядав, буду на неї переїжджати, бо зручніше. і движок БД у нас на жаль MySQL, з PostgreSQL працював мало, щоб використовувати її на всю котушку (хоча на неї теж можна переїхати)
Ну якщо немає необхідності пошуку за цими даними, то чому б і ні. Тільки все ж не погано врахувати розмір серіалізовать даний, як варіант можна використовувати BLOB, якщо вони не зберігаються в рядку, а в бінарному вигляді.
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. це звичайно трохи не по темі, просто крик душі вирвався)
Програміст в душі.
Підхід має місце бути коли ви маєте неструктуровані дані.
Мінусом даного підходу буде лише те, що ви не зможете нормально використовувати серіалізовані дані в запитах + необхідно врахувати зміну структури записуваних даних з часом (тобто ваша програма повинна вміти працювати з усіма версіями даних, які зберігаються в бд).