Как сказать по-русски слово yield???

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

Как сказать по-русски слово yield???

Владимир Мартьянов, литературно все верно конечно, но... хочется сказать как-то по-другому, как не знаю, поэтому и спросил)

Как сказать по-русски слово yield???

Владимир Мартьянов, ну как бы да, похоже...но звучит все равно как-то неестественно, не находите?)

Как сделать вечную авторизацию на сайте?

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

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

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

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

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

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

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

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

Adamos именно

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

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

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

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.: это конечно немного не по теме, просто крик души вырвался)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно ли использовать MongoDB в случае over 200 полей?

и речь как раз не о in-place обновлениях, про них все понятно.

Можно ли использовать MongoDB в случае over 200 полей?

Дмитрий,

Record Storage Characteristics
records are contiguously located on disk, and when a document becomes larger than the allocated record, MongoDB must allocate a new record. New allocations require MongoDB to move a document and update all indexes that refer to the document, which takes more time than in-place updates and leads to storage fragmentation.

Если я правильно все понял, то перераспределение таки происходит) если конечно я читать не разучился

Можно ли использовать MongoDB в случае over 200 полей?

Про размер прекрасно помню. В размер все прекрасно должно влезть, если я правильно все рассчитывал. Проблема в том что при изменении размеров документа Mongo, насколько я понял, делать reallocate, ну или как это назвать. И хотя обновления предполагаются крайне редко, все же непонятно, насколько приемлем тот механизм работы с дисковым пространством как у Mongo.