Сообщение Re[9]: Архитектура доступа к бд от 17.04.2019 17:08
Изменено 17.04.2019 17:12 okon
Re[9]: Архитектура доступа к бд
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, okon, Вы писали:
D>[skip]
D>>>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>>>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
O>>Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
O>>В более менее промышленых решениях которые я встречал там от 100+ таблиц
O>>Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
D>Извините, мы не дизайн базы обговариваем, а способ доступа к ним. Среди пользователей linq2db есть и такие кто говорит об 1000+ таблиц и никто еще на скорость не жаловался.
дело не в 1000+ таблицах а количестве записей.
Но в целом 1000+ таблиц если покажете бенчмарки для linq2db как он справляется автогенеренными запросами, было бы интересно.
Если конечно это не для красного словца сказано.
D>Какой же умник будет миллионы записей на клиент тянуть? Зачем?
Так никто обычно и не тянет миллионы на клиент, но в базе чтобы отфильтровать нужные данные вам придется по этим миллионам пройтись как-то.
При это СУБД всю таблицу к себе в память поместить не может, а также нет возможности по всем кейсами индексы сделать их просто будет миллионы и будет тормозить вставку данных.
D>Здравствуйте, okon, Вы писали:
D>[skip]
D>>>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>>>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
O>>Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
O>>В более менее промышленых решениях которые я встречал там от 100+ таблиц
O>>Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
D>Извините, мы не дизайн базы обговариваем, а способ доступа к ним. Среди пользователей linq2db есть и такие кто говорит об 1000+ таблиц и никто еще на скорость не жаловался.
дело не в 1000+ таблицах а количестве записей.
Но в целом 1000+ таблиц если покажете бенчмарки для linq2db как он справляется автогенеренными запросами, было бы интересно.
Если конечно это не для красного словца сказано.
D>Какой же умник будет миллионы записей на клиент тянуть? Зачем?
Так никто обычно и не тянет миллионы на клиент, но в базе чтобы отфильтровать нужные данные вам придется по этим миллионам пройтись как-то.
При это СУБД всю таблицу к себе в память поместить не может, а также нет возможности по всем кейсами индексы сделать их просто будет миллионы и будет тормозить вставку данных.
Re[9]: Архитектура доступа к бд
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, okon, Вы писали:
D>[skip]
D>>>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>>>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
O>>Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
O>>В более менее промышленых решениях которые я встречал там от 100+ таблиц
O>>Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
D>Извините, мы не дизайн базы обговариваем, а способ доступа к ним. Среди пользователей linq2db есть и такие кто говорит об 1000+ таблиц и никто еще на скорость не жаловался.
дело не в 1000+ таблицах а количестве записей.
Но в целом 1000+ таблиц реальной базы ( как правило там и данных будет 1млн+ ) если покажете бенчмарки для linq2db как он справляется автогенеренными запросами, было бы интересно.
Если конечно это не для красного словца сказано.
D>Какой же умник будет миллионы записей на клиент тянуть? Зачем?
Так никто обычно и не тянет миллионы на клиент, но в базе чтобы отфильтровать нужные данные вам придется по этим миллионам пройтись как-то.
При это СУБД всю таблицу к себе в память поместить не может, а также нет возможности по всем кейсами индексы сделать их просто будет миллионы и будет тормозить вставку данных.
D>Здравствуйте, okon, Вы писали:
D>[skip]
D>>>Любая из 10+ поддерживаемых (уже и сам не помню сколько их)
D>>>Размеры таблиц тут как бы не релевантны. Генерится оптимальный сиквел, а уж как ты индексы настроил — сам себе буратино.
O>>Релевантны, потому что таблицы с 10 000 записей работать будут нормально как правило и без индексов.
O>>В более менее промышленых решениях которые я встречал там от 100+ таблиц
O>>Также от 1+ млн записей, в памяти таблицы не помещаются, индексы по всем вариантам фильтров не построишь.
D>Извините, мы не дизайн базы обговариваем, а способ доступа к ним. Среди пользователей linq2db есть и такие кто говорит об 1000+ таблиц и никто еще на скорость не жаловался.
дело не в 1000+ таблицах а количестве записей.
Но в целом 1000+ таблиц реальной базы ( как правило там и данных будет 1млн+ ) если покажете бенчмарки для linq2db как он справляется автогенеренными запросами, было бы интересно.
Если конечно это не для красного словца сказано.
D>Какой же умник будет миллионы записей на клиент тянуть? Зачем?
Так никто обычно и не тянет миллионы на клиент, но в базе чтобы отфильтровать нужные данные вам придется по этим миллионам пройтись как-то.
При это СУБД всю таблицу к себе в память поместить не может, а также нет возможности по всем кейсами индексы сделать их просто будет миллионы и будет тормозить вставку данных.