Извините, если я выбрал неправильную тему форума. Просто не знаю точно, где задать этот вопрос.
Есть БД в аксесе для анализа детализаций телефонных переговоров. Пока что в ней есть 300 миллионов записей. Предполагается, что через 3 года их будет миллиард.
Изначально в базе было не более 100 тыс записей. Работало все достаточно быстро. Ведь для каждого месяца и здания использовался отдельный файл БД.
Меня попросили объединить все БД, чтобы получить общий анализ за все периоды по всем бизнес-центрам. Я объединил, получил вот такое количество записей. БД теперь тормозит неимоверно. Элементарно открытие таблицы занимает примерно минуту. Вроде не так много, но это только открытие таблицы. Я уж не говорю про какие-то запросы. И это я пока объединяю в MDB. Я не говорю уж про ADP, в который я пока пихать эту общую таблицу звонков не хочу, так как ясно, что через сеть столько данных не пройдет, и серверные фильтры здесь вряд ли особо помогут.
Посоветуйте, пожалуйста, что в этом случае нужно делать? Видимо, первое, это отказаться от Аксеса? А какую БД начать изучать? Oracle или какую-то другую?
Спасибо

Dimitry Sibiryakov
Senya_L
А кроме Access'а у Вас какие-нибудь СУБД используются вообще?

Гораздо интереснее вопрос: а есть ли у них там программисты...


Вопрос логичный и правильный. Отвечу честно и откровенно. Никаких программистов нет. Есть я, который несколько месяцев назад начал изучение аксеса. Пришлось это сделать по-разным причинам. Это уже другой вопрос. Главное, что специалистов в этой области у нас нет. Иначе у меня такого вопроса не стояло бы. Соответственно, сами понимаете, каков мой уровень на данный момент с учетом того, что времени на изучение слишком мало. Уровень слишком низкий. Но достаточный, чтобы создавать простые приложения под свои нужды.
Впринципе, вопрос о скорости запросов не стоит. Как я говорил, они работают моментально при количестве до 100 тыс, что было достаточно.
Вопрос стоит в том, что даже без запросов сама таблица с количеством записей в 300 млн открывается целую минуту. И это на моем домашнем компе, который далеко не самый слабый (хотя покупался 1,5 или 2 года назад, точно не помню). Процессор Кор2Дуо, оперативки 8Гб. Соответственно, это либо акс уже не тянет такое количество записей либо железа недостаточно.
Я сталкиваюсь с такой проблемой впервые, поэтому и спрашиваю. Что влиет на скорость открытия таблицы? Например, любая самая современная игра у меня идет на максимальном разрешении без проблем (может и не любая, я не игроман, но ребенок покупает последние появляющиеся игры и они идут без проблем с максимальным разрешением). Хотя полагаю, что требования к железу для БД и для игр отличаются.

Senya_LSrg999Мне вот непонятно только, как это при таком потоке телефонного трепа, т.е. вроде бы как организация немаленькая, нет программиста?
авторА какую БД начать изучать? Oracle или какую-то другую?Это называется "вопрос ребром": Oracle or not Oracle

Сформулируйте требования к СУБД, если уж надумали выбирать.

Не поверите, но организация немаленькая. Однако, на многом экономит. Мне тоже смешно, когда приходится заниматься не своей работой. А делаю я эти БД исключительно для себя, чтобы работать было проще, так как пока меня эта работа устраивает. И эти БД мне сильно облегчают работу. Но если буду уходить, то все заберу. Я задавал как-то вопрос про удаление БД в зависимости от определенных условий. И сейчас у меня такое реализовано. Если я уйду, то уйду по-хорошему, но у них через 3 запуска моя БД удалится полностью, а тут уж я не знаю, что у них за сбой в компьютере. А так как программистов нет, то никто ничего не поймет. Но это уже другая история.

А что касается Оракла, то я не так много БД знаю. Но из того, что я слышал краем уха, достаточно быстрая БД - это Оракл. Хотя понимаю, что написав это, я выгляжу очень смешно, так как любой профи сразу скажет, что все зависит от требований к СУБД, о чем Вы и спросили, кстати говоря.

Как бы то ни было, если опустить все частности. Можете ли Вы, уважаемые профи, ответить на вопрос. Таблица с 300 миллионами записей в аксесе должна открываться быстро или как у меня минута - это нормальное время? Если Вы скажете, что это нормальное время, значит я буду предполагать, что дело в самом аксесе.

я вас понял, ребят.
Но что касается запросов, то я в принципе отчетные данные получаю именно из запросов. Хотя в данном случае основной инструмент, которым я пользуюсь - это сводная таблица.
Однако, из-за количества записей стали работать медленно и запросы и сводная таблица. Даже простые запросы, где не может быть проблем с неправильным построением, работают медленно.
Насчет жмотов - согласен. Но от этого мне не легче. Хотя мои БД мне сильно облегчают труд.
А в данном случае проблема для меня останется нерешенной. И впринципе, воспользуюсь советом и по данной просьбе пошлю их. Пусть ищут программиста. Лично меня не интересует анализ данных за все годы по всем объектам.
Спасибо

Access denied1Интересно, как в access затолкали 300 000 000 записей?
mdb/accdb - не резиновый, 2Gb макс размер.

авторМеня попросили объединить все БД, Что, прилинковали таблицы из нескольких баз и сделали UNION?

А где один миллиард, там и два, того гляди int32 переполнится

Вы абсолютно правы. Так и сделал. Других вариантов и нет. Или я их не знаю. Я сказал, что я объединил записи, но назвал этот запрос таблицей. Думаю, что как раз в этом и проблема. Union от такого количества записей, наверное, так и должен тормозить. Просто я считал юнион обычным запросом, из-за которого тормозить не должно.
В общем, пошли они нафиг. Я уже понял, что зря с этим связался. Я аксес начал изучать всего несколько месяцев назад, а тут такие задачи просят решать. пипец.
На эту задачу я точно болт забью. Так как уже понял, что мне ее не решить. А если и решить, то явно не при моем нынешнем уровне, а когда-нибудь в лучшие времена. Тут реально нужен толковый программист, а не чайник типа меня, который считал, что запрос UNION то же самое что и таблица. смешно.

Зайцев Фёдорсотни миллионов записей в Access ? Очень похоже на это

вроде того. весело получается.

Funny_FalconPostgreSQL : наследование с партицированием (перенос данных в партиции периодически запускаемым скриптом ).

пока что для меня это дремучий лес. Но по крайней мере я про это почитаю. Глядишь, как аксес, затянет. Спасибо!

Senya_LSrg999А все-таки можно и посоветовать и полезное. Попробуйте собрать промежуточную статистику на местах. Мне трудно советовать конкретику (деталей здесь не обсуждали), но если нужна отчетная информация, то возможно удасться частично сгруппировать результаты филиала.

а вот этот вариант похож на правду. почему я не подумал о нем? чайник потому что.
а похож он на правду не потому, что он самый лучший или единственный, а потому, что его в принципе я смогу и реализовать при желании. Действительно, зачем объединять базы за все месяца, когда проще унифицировать и объединить отчеты. Блин, а это идея. вот чайник, сразу не подумал.
Спасибо Вам огромное за хороший совет! Я уже хотел всех нах послать, а тут появилась возможность мне самому реализовать, как даже самому захотелось попробовать.
А что касается других советов на форуме, то за них тоже спасибо всем, так как я уже читаю и о OLAP-инструментарии и о PostgreSQL вот уже ищу информацию и т.д. В общем, почитаю в любом случае, вредно не будет.

А вообще, буду очень благодарен, если кинете хорошую ссылку, где бы можно было посмотреть подробное сравнение всех имеющихся баз данных. Потому что хочется представлять общую картину. Может я начну осваивать другую БД.