Сообщение Re[7]: Архитектура доступа к бд от 17.04.2019 16:41
Изменено 17.04.2019 16:46 okon
Re[7]: Архитектура доступа к бд
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, okon, Вы писали:
O>>>>На практике ничего лучше работы с OracleConnection/OracleCommand не обнаружил.
D>>>Ну вот представь себе что я уже пару лет не писал запросы в коде вручную. Все прекрастно генерит linq2db.
D>>>То что EF к ним плохо заточен — это спасибо его дизайну и молодости EF Core. Про EF 6 я вообще молчу, да это ужас.
O>>А какая СУБД ? Размеры таблиц ?
D>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
В более менее промышленых решениях которые я встречал там от 100+ таблиц
Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
D>Здравствуйте, okon, Вы писали:
O>>>>На практике ничего лучше работы с OracleConnection/OracleCommand не обнаружил.
D>>>Ну вот представь себе что я уже пару лет не писал запросы в коде вручную. Все прекрастно генерит linq2db.
D>>>То что EF к ним плохо заточен — это спасибо его дизайну и молодости EF Core. Про EF 6 я вообще молчу, да это ужас.
O>>А какая СУБД ? Размеры таблиц ?
D>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
В более менее промышленых решениях которые я встречал там от 100+ таблиц
Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
Re[7]: Архитектура доступа к бд
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, okon, Вы писали:
O>>>>На практике ничего лучше работы с OracleConnection/OracleCommand не обнаружил.
D>>>Ну вот представь себе что я уже пару лет не писал запросы в коде вручную. Все прекрастно генерит linq2db.
D>>>То что EF к ним плохо заточен — это спасибо его дизайну и молодости EF Core. Про EF 6 я вообще молчу, да это ужас.
O>>А какая СУБД ? Размеры таблиц ?
D>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
В более менее промышленых решениях которые я встречал там от 100+ таблиц
Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
p.s. да кстати мы говорим сейчас об архитектуре, так вот что касается всякий внешних библиотек,
типа linq2db и др, в хорошей архитектуре есть рекомендации делать прослойку типа ILinqToDB для того чтобы можно было
легче в будущем избавиться от конкретной библиотеки и использовать другую, особенно когда спецификой этой библиотеки начинает обрастать решение.
D>Здравствуйте, okon, Вы писали:
O>>>>На практике ничего лучше работы с OracleConnection/OracleCommand не обнаружил.
D>>>Ну вот представь себе что я уже пару лет не писал запросы в коде вручную. Все прекрастно генерит linq2db.
D>>>То что EF к ним плохо заточен — это спасибо его дизайну и молодости EF Core. Про EF 6 я вообще молчу, да это ужас.
O>>А какая СУБД ? Размеры таблиц ?
D>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
В более менее промышленых решениях которые я встречал там от 100+ таблиц
Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
p.s. да кстати мы говорим сейчас об архитектуре, так вот что касается всякий внешних библиотек,
типа linq2db и др, в хорошей архитектуре есть рекомендации делать прослойку типа ILinqToDB для того чтобы можно было
легче в будущем избавиться от конкретной библиотеки и использовать другую, особенно когда спецификой этой библиотеки начинает обрастать решение.