Омг, ты свой код килобайтами меряешь? Бгг. Ну держи - c конца декабря. lines = 14667 bytes = 471076 commits = 196 hours = 113 Чем тебе это поможет, я откровенно без понятия. Ты конечно извини, но думать у тебя получается крайне плохо - тренируйся. Это мне? Для меня важно насколько быстро и понятно я могу написать код и сколько раз мне придется его рефакторить. Я не могу отделить одно от другого. И я хочу Но вот реальность (см. запрос) не всегда соответствует действительности Оно мне честно выгребло(точнее попыталось) все что я попросил. Вот только мне нужно было взять 1ну ветку к таблице на 5м этаже, а не все связи. И вот указать это одной строчкой пока нельзя. Таки ускоряет . Для меня во всяком случае это очевидно.
а ха. 2/3 комментариев? нет ну серьёзно, реализация у тебя имхо, жестяная =) хотя может я не понимаю чёрной изюминки класс-монстров =) Kreker обработчик с данными не имеет обратной связи мне вообще его подход не нравится. хотя мне пылевать =) в твоём случае это единственный способ адекватно измерить работу =) ну может есть ещё, но я не знаю. Ps/ ты как строчки посчитал? =)
Мда, вопросов больше не имею, пациент скорее мертв. Обязательно это учтем, как только кому-нибудь в мире потребуется твоя экспертная оценка они будут знать к кому обращаться Вы мне нравитесь оба - вместе с r00les. Сначала пытаетесь ниспровергнуть Фаулера и иже с ними, затем начинаете выпытывать - а как сделать тривиальную вещь В мануал хлопцы.... в мануал и в гугл Там все есть.
Хм, запросы к нескольким таблицам в общем-то все одинаково выглядят. Нет. Это собирались не свойства объекта. В моем случае имеется нормализация. Поэтому, имея, к примеру, номер договора и желая получить текущее местоположение контейнера делается несколько join'ов
Simpliest ну вот, ты разнервничался. ай ай. зря значит тему создал я даже не знаю кто это =) ну я как бы не работаю таким мега кульц. программером, подобные вкусняшки мне не ведомы. и причём тут Фаулер, давно ли он пишет про подсчёт строк? ну вот не знаю как строки подсчитать, пойду теперь напьюсь и буду быстренько учить ZF дабы не прослыть больше в рядах быдлокодеров и поведать великую тайну кодогенеатора. чур меня чур
По мне, так изначально непродуманно были проставлены активные связи. ORM все же инструмент, а не робот-официант, бездумно им махать не нужно. Убери всех все на кастомеров в лейзи лоад. Глупость считать, что ORM направлена на то, что бы решить все одним запросом. Хотя их и стоит уменьшать. В идеале нужно активными связями оставлять самое необходимое - то, что в выборке, то, что неразделимо по логике, остальное в лейзи лоад, но грузить пачкой. Т.е. есть ленивые ссылки на 10 кастомеров - их нужно одной пачкой подгрузить. Если ORM этого не умеет - писать самому "помошники". У нас вроде как была такая ситуация... но мы не парились, так там все из кеша поедет все-равно... точно не помню.
MiksIr Спасибо конечно за совет только я топик начинал, как раз для того чтобы показать Всю работу он за тебя не сделает. Как бы мне или кому-то еще этого ни хотелось В идеале у меня есть идея допилить автогенерацию связей по EER диаграмме. (хотя тут тоже есть нюанс, MySQL в DDL запросах никак не отражает необязательные constraint ) Тогда в коде я буду только указывать начальную и конечную таблицы для выбора ветви графа, а код сам себя будет достраивать. Правда для этого придется промапить обратные ссылки, но это решаемый вопрос Попутно хочу изучить вопрос хранения в MongoDB, пока непонятно позволяет ли он хранить циклические графы. Да и ленивая загрузка пока тоже под вопросом. Сделать-то ее не проблема. Вопрос нужна ли она это ведь не хайлоад и проку от нее может быть меньше чем вреда. Так что когда будет работать, отпрофилирую и будет видно по результатам.