-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Sokil.Dmytro
Новичок
Это будет не просто, потому что непонятно что это
Sokil.Dmytro
Новичок
Хорошие концепции не глохнут, в крайнем случае идеи перенимаются другими проектами
Sokil.Dmytro
Новичок
whirlwind, я знаю что от Creole в пользу нативного PDO отказался Propel, а автор Creole заявил что проект здох. По этому я действительно не знаю о чем идет речь, и нисколько по этому поводу не переживаю. Насинг персонал. Я вообще придерживаюсь мысли что особой надобности в постоянных миграциях между БД нету, а по этому надо забить на неабстрагируемые куски кода и писать их напрямую, или выделять в отдельные классы, все равно плавного переезда не получится никак. Да и производительность будет получше, чем пытаться уминать все к однотипности
Какая прекрасная в своей бессмысленности фраза!
whirlwind
TDD infected, paranoid
Sokil.Dmytro просто ты не сталкивался. Производительность будет повыше как раз на элементарных (SQL92) запросах. А креол обеспечивает спокойную миграцию mysql-pgsql+sqlite. Этого достаточно для большинства задач. Как в тестах: если у вас возникает сложный запрос, значит вы что-то делаете не так. Креол может и сдох, но он хорош даже такой как есть. Потому что он порт jdbc, а все что с java, как показывет практика, очень хорошее ооп. Отказываться от него в пользу PDO, разработанного процедурщиками, нет никакого смысла.
Sokil.Dmytro
Новичок
Согласен про простые. Не согласен про сложные, потому что сложные иногда бывают оправданными. Вот например реализацию Netsed Sets врядле абстрагируешь используя строитель запросов. Там куча мутных условий и прочего. Тут лучше делать абстракцию от БД уже целых запросов, а не по принципу квери билдеров. Вот я и говорю что для простых запросов удобно всякие квери билдеры, чтобы делать елементарные выборки строк с базы. Оно и удобно и наглядно. А для всего остального - инкапсуляция целых запросов в методы класса двайвера, а потом с помощью фабрики получать к драйверу доступ.
Хоть он и порт, но портирует он максимум API jdbc, а в остальном все равно работает поверх нативных библиотек доступа к СУБД. Кстати есть сорсы? А то гугл в упор ниче не хочет давать.
Вообще, эта фраза очень хорошо показывает, что ты не понимаешь, что такое ООП. Вот как раз в той части, где «Один из вариантов - абстракция для хранилища.» Ты говоришь лишь об ООП-синтаксисе, это все равно что рассуждать об аэродинамических свойствах ложки, когда разговор идет о супе, который нужно есть.
whirlwind
TDD infected, paranoid
> Вот например реализацию Netsed Sets врядле абстрагируешь.
С чего это? Все там прекрасно ложится. Там же чисто математический алгоритм. Не могу найти реализации у себя, но если интересно, люди повылязят с каникул нарою проект один. Все там пучком асбтрагируется через тот же SQL92. Сорцы действительно чета с тигриса нету. Вроде раньше они билды делали. Ну вот отсюда можешь взять svn://prolib.ru/tools/creole
С чего это? Все там прекрасно ложится. Там же чисто математический алгоритм. Не могу найти реализации у себя, но если интересно, люди повылязят с каникул нарою проект один. Все там пучком асбтрагируется через тот же SQL92. Сорцы действительно чета с тигриса нету. Вроде раньше они билды делали. Ну вот отсюда можешь взять svn://prolib.ru/tools/creole
Оффтоп: я на этом форуме очень-очень уважаю AmdY и grigori. Одни из немногих людей, которые не стесняются сказать «Ерунду сморозил, извините.» И при этом не пытаются оправдаться чем-то вроде «Да я бухал/не спал/с девками гулял последние двое суток и поэтому слегка устал!». Отличные люди, правда. Сам пытаюсь таким быть, да.
Chusha
Юношеский максимализм?
Я не слышал о существовании СУБД, которая полностью поддерживала какой-либо из последних стандартов SQL.
Замена движка - это практически миф. В не коробочных продуктах СУБД как и прочие компоненты выбираются под задачу с учетом внешних условий и используются так, что-бы получить от этих компонент максимальную отдачу вне зависимости от поддерживаемых стандартов.
P.S> А подолью ка я масла в огонь)
Вообще все ваше ООП - тормознутое и глючит! В последнем проекте на 15к строк ООП-С++ кода мне пришлось переписать целых 3 функции на ассемблере и получить примерно +40% к производительности всего проекта.
Юношеский максимализм?
Я не слышал о существовании СУБД, которая полностью поддерживала какой-либо из последних стандартов SQL.
Замена движка - это практически миф. В не коробочных продуктах СУБД как и прочие компоненты выбираются под задачу с учетом внешних условий и используются так, что-бы получить от этих компонент максимальную отдачу вне зависимости от поддерживаемых стандартов.
P.S> А подолью ка я масла в огонь
)Вообще все ваше ООП - тормознутое и глючит! В последнем проекте на 15к строк ООП-С++ кода мне пришлось переписать целых 3 функции на ассемблере и получить примерно +40% к производительности всего проекта.
2,5 дня работы программиста значительно дешевле на 40% более производительного сервера. А так как арифметика,геометрия,алгебра,итд в ближайшее время меняться не планируют, то думаю эти 300 строк ассемблера еще долго никто менять не будет. Тем более что оригинальный код никто не удалял и при сборке можно одним флагом переключиться с С-кода на асм и наоборот.
Суть в том, что если нам надо к примеру вычислить объем гиперграней 256мерного додекаэдра и мы используем метод суммирования единичных объемов, то алгоритм самого метода уже никогда не изменится. А если будет определен другой метод с другим алгоритмом, то его точно так-же с нуля придется писать хоть на С, хоть на ассемблере, хоть на чем угодно. (Все названия являются вымышленными, любое совпадение с реальностью случайно
)
ага, спасибо