Сообщение Re[9]: [proof-of-concept] compile time query language от 14.07.2016 11:45
Изменено 14.07.2016 11:50 chaotic-kotik
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?
Отдельную ф-ю на каждый вариант проектции делать не нужно, ее нужно делать на каждый поддерживаемый тип данных, ф-я при этом должна принимать фильтр, который строится в runtime динамически. Поинт в том, чтобы приложение работало с объектами класса Publisher и Placement а не с таблицами, проекциями и джоинами.
EP>Так а в чём профит?
EP>Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?
Простой пример, приложение работающее с каталогом — есть две таблицы, которые обозначают модель мобильного телефона и конкретное устройство, скажем iPhone 6s и 64х гигабайтная версия iPhone 6s. Пользователю показывают в каталоге продуктов iPhone 6s, когда он по нему кликает — показывают список устройств с разным объемом памяти и размером экрана. Чтобы показать все параметры нужно сделать join двух таблиц. Мы попрофилировали и поняли, что джоин съедает дофига, нужно денормализовать эти две таблицы сделав одну. Теперь мы можем одним select-ом выбрать iPhone 6s 64GB и там будут данные, которые раньше лежали в двух таблицах, таблице моделей и таблице устройств.
Теперь я пойду в код и поменяю один файл с кодом в своем dal, а ты будешь искать в коде все функции, использующие эти таблицы. Мне не нужно будет менять прикладную логику вообще, я смогу сделать так, что код будет работать и со старой схемой и с новой не напрягаясь (dal сможет определить при подключении с какой схемой ему предстоит работать) и прикладной код вообще не изменится. Когда я мигрирую схему в проде, мне даже не придется перезапускать сервисы, так как после shutdown-а БД сервис заново подключится к ней и начнет использовать код, умеющий работать с новой схемой. Собственно для всего этого и нужен динамизм и поэтому запросы, размазанные по коду (пусть и проверяющиеся в compile time компилятором С++) не работают.
EP>За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.
Ты предлагаешь парадоксальную вещь — рефакторить схему БД в коде. Изменили имя поля — рефакторить? Суть БД в том, что приложению класть на layout данных в БД, для этого есть SQL. Маппинг твоей объектной модели на поля таблиц БД должен быть не кодом а конфигурацией. Изменил схему — поменяй конфиг. Можно конечно этот конфиг хранить в коде приложения и генерировать запросы в compile-time, но вообще лучше подкачивать его из БД.
EP>Во-вторых, если у нас в любом случае есть compile-time EDSL запросов (а-ля sqlpp11) и можно достаточно просто (используя новые версии C++, Hana-style и т.п.) оптимизировать в том числе и эти моменты — то почему бы и нет.
Потому что это очень ограниченный способ.
EP>Вот только в DAL ты будешь путаться в индексах, а EDSL это разрулит автоматом.
EP>Более того, в той КСВ теме даже были заявления, что мол руками никто код с индексами и не пишет, вместо этого используют более медленные варианты (этим оправдывали сравнение EDSL варианта на индексах, против ручного варианта без индексов).
Тоже мне проблема, индексы
EP>Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?
Отдельную ф-ю на каждый вариант проектции делать не нужно, ее нужно делать на каждый поддерживаемый тип данных, ф-я при этом должна принимать фильтр, который строится в runtime динамически. Поинт в том, чтобы приложение работало с объектами класса Publisher и Placement а не с таблицами, проекциями и джоинами.
EP>Так а в чём профит?
EP>Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?
Простой пример, приложение работающее с каталогом — есть две таблицы, которые обозначают модель мобильного телефона и конкретное устройство, скажем iPhone 6s и 64х гигабайтная версия iPhone 6s. Пользователю показывают в каталоге продуктов iPhone 6s, когда он по нему кликает — показывают список устройств с разным объемом памяти и размером экрана. Чтобы показать все параметры нужно сделать join двух таблиц. Мы попрофилировали и поняли, что джоин съедает дофига, нужно денормализовать эти две таблицы сделав одну. Теперь мы можем одним select-ом выбрать iPhone 6s 64GB и там будут данные, которые раньше лежали в двух таблицах, таблице моделей и таблице устройств.
Теперь я пойду в код и поменяю один файл с кодом в своем dal, а ты будешь искать в коде все функции, использующие эти таблицы. Мне не нужно будет менять прикладную логику вообще, я смогу сделать так, что код будет работать и со старой схемой и с новой не напрягаясь (dal сможет определить при подключении с какой схемой ему предстоит работать) и прикладной код вообще не изменится. Когда я мигрирую схему в проде, мне даже не придется перезапускать сервисы, так как после shutdown-а БД сервис заново подключится к ней и начнет использовать код, умеющий работать с новой схемой. Собственно для всего этого и нужен динамизм и поэтому запросы, размазанные по коду (пусть и проверяющиеся в compile time компилятором С++) не работают.
EP>За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.
Ты предлагаешь парадоксальную вещь — рефакторить схему БД в коде. Изменили имя поля — рефакторить? Суть БД в том, что приложению класть на layout данных в БД, для этого есть SQL. Маппинг твоей объектной модели на поля таблиц БД должен быть не кодом а конфигурацией. Изменил схему — поменяй конфиг. Можно конечно этот конфиг хранить в коде приложения и генерировать запросы в compile-time, но вообще лучше подкачивать его из БД.
EP>Во-вторых, если у нас в любом случае есть compile-time EDSL запросов (а-ля sqlpp11) и можно достаточно просто (используя новые версии C++, Hana-style и т.п.) оптимизировать в том числе и эти моменты — то почему бы и нет.
Потому что это очень ограниченный способ.
EP>Вот только в DAL ты будешь путаться в индексах, а EDSL это разрулит автоматом.
EP>Более того, в той КСВ теме даже были заявления, что мол руками никто код с индексами и не пишет, вместо этого используют более медленные варианты (этим оправдывали сравнение EDSL варианта на индексах, против ручного варианта без индексов).
Тоже мне проблема, индексы
Re[9]: [proof-of-concept] compile time query language
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?
Отдельную ф-ю на каждый вариант проектции делать не нужно, ее нужно делать на каждый поддерживаемый тип данных, ф-я при этом должна принимать фильтр, который строится в runtime динамически. Поинт в том, чтобы приложение работало с объектами класса Publisher и Placement а не с таблицами, проекциями и джоинами.
EP>Так а в чём профит?
EP>Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?
Простой пример, приложение работающее с каталогом — есть две таблицы, которые обозначают модель мобильного телефона и конкретное устройство, скажем iPhone 6s и 64х гигабайтная версия iPhone 6s. Пользователю показывают в каталоге продуктов iPhone 6s, когда он по нему кликает — показывают список устройств с разным объемом памяти и размером экрана. Чтобы показать все параметры нужно сделать join двух таблиц. Мы попрофилировали и поняли, что джоин съедает дофига, нужно денормализовать эти две таблицы сделав одну. Теперь мы можем одним select-ом выбрать iPhone 6s 64GB устройство или iPhone 6s модель телефона и там будут все нужные данные.
Теперь я пойду в код и поменяю один файл с кодом в своем dal, а ты будешь искать в коде все функции, использующие эти таблицы. Мне не нужно будет менять прикладную логику вообще, я смогу сделать так, что код будет работать и со старой схемой и с новой не напрягаясь (dal сможет определить при подключении с какой схемой ему предстоит работать) и прикладной код вообще не изменится. Когда я мигрирую схему в проде, мне даже не придется перезапускать сервисы, так как после рестарта БД сервис заново подключится к ней и начнет использовать код, умеющий работать с новой схемой. Собственно для всего этого и нужен динамизм и поэтому запросы, размазанные по коду (пусть и проверяющиеся в compile time компилятором С++) не работают.
EP>За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.
Ты предлагаешь парадоксальную вещь — рефакторить схему БД в коде. Изменили имя поля — рефакторить? Суть БД в том, что приложению класть на layout данных в БД, для этого есть SQL. Маппинг твоей объектной модели на поля таблиц БД должен быть не кодом а конфигурацией. Изменил схему — поменяй конфиг. Можно конечно этот конфиг хранить в коде приложения и генерировать запросы в compile-time, но вообще лучше подкачивать его из БД.
EP>Во-вторых, если у нас в любом случае есть compile-time EDSL запросов (а-ля sqlpp11) и можно достаточно просто (используя новые версии C++, Hana-style и т.п.) оптимизировать в том числе и эти моменты — то почему бы и нет.
Потому что это очень ограниченный способ.
EP>Вот только в DAL ты будешь путаться в индексах, а EDSL это разрулит автоматом.
EP>Более того, в той КСВ теме даже были заявления, что мол руками никто код с индексами и не пишет, вместо этого используют более медленные варианты (этим оправдывали сравнение EDSL варианта на индексах, против ручного варианта без индексов).
Тоже мне проблема, индексы
EP>Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?
Отдельную ф-ю на каждый вариант проектции делать не нужно, ее нужно делать на каждый поддерживаемый тип данных, ф-я при этом должна принимать фильтр, который строится в runtime динамически. Поинт в том, чтобы приложение работало с объектами класса Publisher и Placement а не с таблицами, проекциями и джоинами.
EP>Так а в чём профит?
EP>Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?
Простой пример, приложение работающее с каталогом — есть две таблицы, которые обозначают модель мобильного телефона и конкретное устройство, скажем iPhone 6s и 64х гигабайтная версия iPhone 6s. Пользователю показывают в каталоге продуктов iPhone 6s, когда он по нему кликает — показывают список устройств с разным объемом памяти и размером экрана. Чтобы показать все параметры нужно сделать join двух таблиц. Мы попрофилировали и поняли, что джоин съедает дофига, нужно денормализовать эти две таблицы сделав одну. Теперь мы можем одним select-ом выбрать iPhone 6s 64GB устройство или iPhone 6s модель телефона и там будут все нужные данные.
Теперь я пойду в код и поменяю один файл с кодом в своем dal, а ты будешь искать в коде все функции, использующие эти таблицы. Мне не нужно будет менять прикладную логику вообще, я смогу сделать так, что код будет работать и со старой схемой и с новой не напрягаясь (dal сможет определить при подключении с какой схемой ему предстоит работать) и прикладной код вообще не изменится. Когда я мигрирую схему в проде, мне даже не придется перезапускать сервисы, так как после рестарта БД сервис заново подключится к ней и начнет использовать код, умеющий работать с новой схемой. Собственно для всего этого и нужен динамизм и поэтому запросы, размазанные по коду (пусть и проверяющиеся в compile time компилятором С++) не работают.
EP>За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.
Ты предлагаешь парадоксальную вещь — рефакторить схему БД в коде. Изменили имя поля — рефакторить? Суть БД в том, что приложению класть на layout данных в БД, для этого есть SQL. Маппинг твоей объектной модели на поля таблиц БД должен быть не кодом а конфигурацией. Изменил схему — поменяй конфиг. Можно конечно этот конфиг хранить в коде приложения и генерировать запросы в compile-time, но вообще лучше подкачивать его из БД.
EP>Во-вторых, если у нас в любом случае есть compile-time EDSL запросов (а-ля sqlpp11) и можно достаточно просто (используя новые версии C++, Hana-style и т.п.) оптимизировать в том числе и эти моменты — то почему бы и нет.
Потому что это очень ограниченный способ.
EP>Вот только в DAL ты будешь путаться в индексах, а EDSL это разрулит автоматом.
EP>Более того, в той КСВ теме даже были заявления, что мол руками никто код с индексами и не пишет, вместо этого используют более медленные варианты (этим оправдывали сравнение EDSL варианта на индексах, против ручного варианта без индексов).
Тоже мне проблема, индексы