Сообщение Re[38]: EntityFramework - тормоз от 20.04.2015 7:03
Изменено 20.04.2015 7:04 Mamut [ищите в других сетях]
M>>Любой «независимый от баз данных» слой сможет покрыть только общий для всех баз данных функционал + некоторое количество хаков для некоторых вещей. Ну типа генерация последовательностей для баз данных, где последовательностей не существует. Или грязные хаки для windowing functions.
_>Безусловно движку, умеющему работать с разными СУБД, приходится ограничиваться пересечением функционала этих СУБД. Но на самом деле этого обычно вполне достаточно, т.к. во всех нормальных СУБД есть всё нужное.
Покажи мне windowing functions в MySQL.
Покажи мне generate_series не в PostgreSQL.
Хот да, неизвестно же, что ты считаешь «нормальными базами данных» :-
_>Там основная проблема скорее в другом — в разных СУБД эта функциональность может по разному подключаться.
M>>Как только нужна внятная быстрая функциональность за пределами банальных джойнов или запросы, которые учитывают порядок индексов (что важно для, например, mysql'я), то вся «независимая прослойка» летит к черту.
_>Эммм, по нормальному за пределами слоя работы с БД никаких джойнов и т.п. не должно быть. )
M>>Если база данных не поддерживает PostgreSQL'овское generate_series, то тебе никакая магическая абстракция не поможет. И приложение будет моментально привязано к PostgreSQL как только это понадобится (а оно понадобится)
_>Такими темпами он может когда-нибудь выйти в однозначные лидеры и тогда можно будет спокойно затачиваться под него — вот будет счастье для авторов всяких движков. ))) Но пока до этого ещё далеко.
Мдеее. Теоретики такие теоретики. «Нормальные базы данных», «всего лишь реализовать функционал», «однозначные лидеры».
Достаточно того, что на первых трех местах несовместимые друг с другом по функционалу базы данных.
Можно начать, например, с hierarchical queries и windowing functions. Ну или, повторю, с generate_sequence.
_>Безусловно движку, умеющему работать с разными СУБД, приходится ограничиваться пересечением функционала этих СУБД. Но на самом деле этого обычно вполне достаточно, т.к. во всех нормальных СУБД есть всё нужное.
Покажи мне windowing functions в MySQL.
Покажи мне generate_series не в PostgreSQL.
Хот да, неизвестно же, что ты считаешь «нормальными базами данных» :-
_>Там основная проблема скорее в другом — в разных СУБД эта функциональность может по разному подключаться.
M>>Как только нужна внятная быстрая функциональность за пределами банальных джойнов или запросы, которые учитывают порядок индексов (что важно для, например, mysql'я), то вся «независимая прослойка» летит к черту.
_>Эммм, по нормальному за пределами слоя работы с БД никаких джойнов и т.п. не должно быть. )
M>>Если база данных не поддерживает PostgreSQL'овское generate_series, то тебе никакая магическая абстракция не поможет. И приложение будет моментально привязано к PostgreSQL как только это понадобится (а оно понадобится)
_>Такими темпами он может когда-нибудь выйти в однозначные лидеры и тогда можно будет спокойно затачиваться под него — вот будет счастье для авторов всяких движков. ))) Но пока до этого ещё далеко.
Мдеее. Теоретики такие теоретики. «Нормальные базы данных», «всего лишь реализовать функционал», «однозначные лидеры».
Достаточно того, что на первых трех местах несовместимые друг с другом по функционалу базы данных.
Можно начать, например, с hierarchical queries и windowing functions. Ну или, повторю, с generate_sequence.
Re[38]: EntityFramework - тормоз
M>>Любой «независимый от баз данных» слой сможет покрыть только общий для всех баз данных функционал + некоторое количество хаков для некоторых вещей. Ну типа генерация последовательностей для баз данных, где последовательностей не существует. Или грязные хаки для windowing functions.
_>Безусловно движку, умеющему работать с разными СУБД, приходится ограничиваться пересечением функционала этих СУБД. Но на самом деле этого обычно вполне достаточно, т.к. во всех нормальных СУБД есть всё нужное.
Покажи мне windowing functions в MySQL.
Покажи мне generate_series не в PostgreSQL.
Хот да, неизвестно же, что ты считаешь «нормальными базами данных»
_>Там основная проблема скорее в другом — в разных СУБД эта функциональность может по разному подключаться.
_>Такими темпами он может когда-нибудь выйти в однозначные лидеры и тогда можно будет спокойно затачиваться под него — вот будет счастье для авторов всяких движков. ))) Но пока до этого ещё далеко.
Мдеее. Теоретики такие теоретики. «Нормальные базы данных», «всего лишь реализовать функционал», «однозначные лидеры».
Достаточно того, что на первых трех местах несовместимые друг с другом по функционалу базы данных.
Можно начать, например, с hierarchical queries и windowing functions. Ну или, повторю, с generate_sequence.
_>Безусловно движку, умеющему работать с разными СУБД, приходится ограничиваться пересечением функционала этих СУБД. Но на самом деле этого обычно вполне достаточно, т.к. во всех нормальных СУБД есть всё нужное.
Покажи мне windowing functions в MySQL.
Покажи мне generate_series не в PostgreSQL.
Хот да, неизвестно же, что ты считаешь «нормальными базами данных»
_>Там основная проблема скорее в другом — в разных СУБД эта функциональность может по разному подключаться.
_>Такими темпами он может когда-нибудь выйти в однозначные лидеры и тогда можно будет спокойно затачиваться под него — вот будет счастье для авторов всяких движков. ))) Но пока до этого ещё далеко.
Мдеее. Теоретики такие теоретики. «Нормальные базы данных», «всего лишь реализовать функционал», «однозначные лидеры».
Достаточно того, что на первых трех местах несовместимые друг с другом по функционалу базы данных.
Можно начать, например, с hierarchical queries и windowing functions. Ну или, повторю, с generate_sequence.