Объединение баз больше 2 Гб

Аналогичные темы на форуме прочла, но решения проблемы с объемом баз не нашла.

Имеем:
6 таблиц csv по 1.9 ГБ каждая. Структура таблиц одинаковая

Access их импортировать отказывается - ругается на общий объем базы больше 2 Гб (по одной таблице на каждую базу тоже), поэтому в Access они связаны.

Нужно: все 6 таблиц объединить в одном файле.

Что пробовала:
Создавать новую связанную таблицу - запросом добавлять в нее строки из таблиц с данными. 1 раз прокатило, создалась таблица на 4Гб (таблицу, в которую добавляла строки, создала копированием одного из csv файлов, т.е. 2 таблицы объединить получилось). Дальше ругается - говорит, либо база больше 2ГБ, либо у тебя на диске нет места. На диске террабайт.

Хелп плз: может ли Access в принципе оперировать с таблицами больше 2 Гб? Объединять, добавлять строки, брать из них данные.

С программированием не дружу, запросы sql минимально редактирую в Access, но все остальные sql-программы мне не дались. На курсы записалась, но решать задачу нужно сейчас ((

0

Сообщение от compin Нужно: все 6 таблиц объединить в одном файле. ((

А что дальше мечтаете делать с монстром в 12гб

0

вытаскивать из него данные по критериям, пересекать его с другими базами (т.е., например, найти все строки, которые есть в "монстре" и в базе "клиенты", составить сводную таблицу с данными из монстра и с данными о клиентах.

В общем я с этими базами бьюсь уже давно, и каждый процесс (inner join, например) повторяю по 6 раз - вытаскивая данные из каждой таблицы. Поэтому есть желание объединить их в одну.

Добавлено через 2 минуты
UPD: попыталась файлы объединить через командную строку через copy /b *.csv all.csv . Cmd утверждает, что все объединила, файл на 10 гигов лежит, но acces с ним связывать базу отказывается - говорит bad filename or number.

0

Скорее всего БД не нормализована и вместо кодов - текст, плюс наверное и картинки, вот и весят так много, а так бы раз 10-20 наверное все ужалось бы и еще столько можно было бы впихнуть в одну БД.

0

У MS Access ограничение на размер БД = 2GB (к сожалению)
см: Спецификации Access 2010
На практике он начинает "спотыкаться" уже на размерах в районе 1,8GB.
Как вариант:
- разбить данные по определённому признаку и хранить в разных файлах динамически между ними переключаясь.
- использовать иную БД (MS SQL Express, MySQL ... и пр.)
- попробовать нормализовать данные - возможно не так всё страшно.

0

Сообщение от compin каждый процесс (inner join, например) повторяю по 6 раз - вытаскивая данные из каждой таблицы.

применяла неоднократно и не страдала от этого
у меня база была разделена по году

если мне был нужен 2005 год --открывала базу бд2005 --это был основной режим работы
если требовалось несколько лет(например итоги) --применяла временную таблицу для накопления итогов и VBA

0

Сообщение от Eugene-LS - использовать иную БД (MS SQL Express

почему иную? в связке! у меня таблицы в MS SQL например, очень удобно и больше возможностей.

0

Так... я и имел ввиду "для хранения больших данных использовать иную БД подключая ея к MSA".

И ысшо (я забыл выше написать), при обработке больших данных лучше выставлять в запросах на изменение свойство:
Use Transaction = No (Использовать Транзакцию = Нет)
- будет побыстрее и размер расти не так будет, но без отката выполнения.

0

Скорее всего БД не нормализована и вместо кодов - текст, плюс наверное и картинки, вот и весят так много, а так бы раз 10-20 наверное все ужалось бы и еще столько можно было бы впихнуть в одну БД.

картинок нет. только текст. Там несколько миллионов строк.

Добавлено через 2 минуты

У MS Access ограничение на размер БД = 2GB (к сожалению)

Это если импортировать данные в базу Access. А если связать внешнюю базу - тоже ограничение 2ГБ?

0

текст или мемо?

0

применяла неоднократно и не страдала от этого у меня база была разделена по году если мне был нужен 2005 год --открывала базу бд2005 --это был основной режим работы

У меня базы разделены не по году, а по ID . Т.е. ID до 200000 - 1 часть, ID от 200000 до 400000 - другая часть. И т.д. до 1200000. Соответственно всегда нужны все части. И повторять один и тот же запрос 6 раз очень неудобно. Каждый запрос выполняется долго, т.е. это я должна сидеть над компьютером и ждать выполнения запроса, чтобы запустить новый. Поэтому хочется одну базу, запустил запрос работать на ночь и ушел заниматься своими делами.

Да, циклические запросы писать я еще не научилась. Это решило бы проблему.

0

в любом случае всё нужно переводить на MS SQL Server

0

текст или мемо?

числовой и короткий текст
у исходных таблиц (которые в csv) какие-то приколы с кодировками - при импорте Access их воспринимает то как вьетнамскую, то как турецкую кодировку. Возможно, из-за этого, когда я их все в одну таблицу слила, он захлебнулся при попытке импорта.

Добавлено через 2 минуты
С MS SQL Server у меня не сложилось. Поставила его, потупила на него несколько дней, научилась импортировать в него таблицы, но на этапе составления запросов поняла, что мне это не дано. С Access бьюсь только из-за конструктора запросов. На данном уровне знаний о языках запросов это предел моего понимания.

0

Сообщение от compin но на этапе составления запросов поняла, что мне это не дано.

а я про запросы не писал, запросы пишите в Акцесс.

0

спасиб, попробую. Для меня пока даже свою базу MS SQL найти - уже задача на минут 30 раздумий. Я обычно софт легко осваиваю, cms, парсеры, верстаю на html, в php могу хотя бы понять код.... Но этот уже где-то за пределами зоны ближайшего развития.

0

compin, Вы бы хоть урезаный примерчик с 5-10 записями своей огромной таблички выложили, дабы иметь представление о чем уже больше суток все рассуждают, но пришли к выводу, что послать вас в туда, где вы почти не ориентируетесь.

0

Сообщение от PuhKMV compin, Вы бы хоть урезаный примерчик с 5-10 записями своей огромной таблички выложили, дабы иметь представление о чем уже больше суток все рассуждают, но пришли к выводу, что послать вас в туда, где вы почти не ориентируетесь.

Вот такого счастья 19 млн строк в одной базе. Баз 6.

Миниатюры

 

Вложения

example.xlsx (10.2 Кб, 11 просмотров)

0

Сообщение от compin ...Вот такого счастья...

Ну да, тут в принципе если и создать справочники для полей - Статус и - Название группы, не намного вес БД уменьшится, я думал полей с одинаковыми значениями будет 20-50.
Похоже на самом деле тут нужно что то более мощное чем - Access.

0

Основные задачи, которые я с этими базами решаю:
- выборки из всех 6 частей базы по критериям. Например, по вхождению ключевого слова в поле "название" (like *...*)
- фильтрация по условиям: число в столбце Подписчики больше N, отобрать все "ID пользователя", которым соответствует больше X значений в столбце "url группы" (данные в каждом столбце не уникальны: одному ID пользователя может соответствовать несколько десятков строк в разных кусочках базы, с разными ID группы и остальными данными. Рекордсмены там - по 1200 строк на одного ID пользователя.)
- отобрать все строки из всех 6 кусочков базы, в которых значение "ID пользователя" соответствует (inner join) значению в десятках других моих баз.

Т.е., конечно, мне было бы проще, если бы это все было в одной связанной базе, с которой я уже дальше смогу работать.

Добавлено через 2 минуты

Сообщение от PuhKMV Ну да, тут в принципе если и создать справочники для полей - Статус и - Название группы, не намного вес БД уменьшится, я думал полей с одинаковыми значениями будет 20-50. Похоже на самом деле тут нужно что то более мощное чем - Access.

Если все-таки суметь слить все это щастье в один csv и втянуть его в Access как связанную базу - оно сможет с ним работать? Или помрет? И если сможет, то как лучше их объединить?

В принципе, я могу 2-3 столбца из всех баз удалить, если это облегчит мою проблему. Там есть столбцы, которые частично дублируют друг друга и для моего анализа решающего значения не имеют. В конце концов их всегда можно будет подтянуть из исходников баз, если они мне потребуются. Столбцы сильно повлияют на вес базы? или больше влияют строки?

Добавлено через 6 минут
ЗЫ. Статус и Название группы - там не одинаковые значения. Они могут казаться одинаковыми, но всегда хоть чем-то да отличаются. Полностью идентичных значений там будет не больше 5-10 копий на 1 значение справочника, а абсолютно уникальных будут миллионы.

0

Сообщение от compin ...Статус и Название группы - там не одинаковые значения....

Имелось в виду, что у вас к примеру слово
- Реклама
и
- Реклама. (с точкой)
обозначают одно и тоже, но написаны по идее по разному, типа это уже не одно, а два разных значения.
Если нормализовать БД, то этого не будет, т. к. сможете в поле со списком выбрать только то или иное значение (Какое введете в справочник - Статусы)
В основную таблицу будут вводиться только коды (Чиселки), соответствующие определенному тексту.
Как вы думаете что по байтам больше весит
Число из справочника в 2-3 цыферки или несколько слов (имеется в виду многократное повторение в миллионе записей)
А есть еще и второе поле - название группы
Где названия судя по всему так же повторяются.
Что меньше в байтах весит -Число или-Текст?
На малом количестве записей это не сильно заметно, но уже после 500, разница существенная (На сколько я знаю), а у вас миллионы.
Если акцесс, по любому наверное стоит попробовать нормализовать, тем более поля индексировываются, что в десятки, а то и сотни раз уменьшает скорость обработки.
Я конечно любитель и мог бы попробовать помочь. но я тягомотный тугодум и у меня это займет крайне много времени.
Возможно кто то из профессионалов быстрее поможет.

0