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

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

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

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

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

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

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

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

0

После просмотра «Примерчика», возникают такие мысли:
Импортировать в базу MS Access можно – и на вскидку … должно поместится прибл. 25-30 миллионов записей в 2 GB.
- Создаём отдельную таблицу «Группы» и связь по ID группы- один ко многим с таблицей «Пользователи»

Таблица «Пользователи» :
- Поле ссылка на пользователя – IMHO НЕ НУЖНА т.к. може сформировать автоматом по ID
Ссылка = “https://vk.com/id” & [UserID]
- пользователь не может принадлежать разным группам …
- Название группы – вынесено отдельно (оставляем только её ID) – и тут у меня вопрос – а вдруг пользователь может принадлежать к разным группам?
- С полем «Подписчики» - совсем не понятно – их же несколько – так там Многие – ко многим – через промежуточную …. (и возможно в отдельном файле))

Импорт:
Я бы производил импорт в 2 прохода, с начала в «грязную» - потом в «чистую» из грязной.
Порядок импорта примерно такой:
01 -Импортируем часть данных в грязную с номерами (ID) от 1 до 5000000 (например)
02- Нормализуем данные
03- Импортируем в «чистую»
04 – чистим от данных и обжимаем «грязную»
– повторяем всё для следующей группы данных (ID Between 5 000 000 And 10 000 000)

Должно получится.

0

таблица явно не нормализована

прим	id группы	подписчики	название группы	ссылка на группу https://vk.com	-	id пользо	ссылка на пользователя https://vk.com	статус
	75993838	1008899	Игра Долина Сладостей - официальная группа	candyvalley		304787280	id304787280	все вопросы - ко мне
	76271043	129368	Есьже, я приезжий! [KZ]	eap_kz1		265769051	id265769051	admin
31	76084650	495545	FACTS	facts_mirs		274898930	id274898930	Реклама
32	76084650	495545	FACTS	facts_mirs		210301644	id210301644	тоже следит за нашими новостями
	76132198	254486	Stop Fake! ` Полезно знать	good.knowledge		6937230	id6937230	-
	76157815	133911	nightmare	marwert		139424200	id139424200	по всем вопросам
	76105995	117801	Morena	moreena777		282582595	id282582595	Реклама.
	76256400	139798	Бесплатная Москва	moscownomoney		336249359	id336249359	по вопросам размещения конкурсов и рекламы
21	76277458	132165	Rainbow Loom Bands. Видеоуроки на русском языке.	myloomru		90537975	id90537975	Модератор
22	76277458	132165	Rainbow Loom Bands. Видеоуроки на русском языке.	myloomru		276800427	id276800427	Помощник Сергея
	76178873	634753	Что-то нереальное	nohrd		269607146	id269607146	-
	76256545	155395	Бесплатный Питер	piternomoney		336249359	id336249359	по вопросам размещения конкурсов и рекламы
	76265285	240734	Простые рецепты со вкусом	prostyeretcepty		7059077	id7059077	-
	76181005	171329	Факт дня	pub_fact		267259188	id267259188	Реклама
11	76163137	214506	Душевные иллюстрации ` арт, искусство	tenderart		208154216	id208154216	По рекламе
11	76163137	214506	Душевные иллюстрации ` арт, искусство	tenderart		151165264	id151165264	Создатель проекта
	76032052	106955	«ТАНЦЫ» на ТНТ: Битва сезонов	tnt_dance_online		315260742	id315260742	Реклама, сотрудничество, PR
	76048865	801137	young and tragic	youngtragic		151313694	id151313694	-

0

Сообщение от PuhKMV Имелось в виду, что у вас к примеру слово - Реклама и - Реклама. (с точкой) обозначают одно и тоже, но написаны по идее по разному, типа это уже не одно, а два разных значения.

Эти данные не вводятся. Они парсятся из внешних источников. И привести к справочнику в поле Статус можно будет порядка 10% данных, все остальные будут уникальны. В поле "Название группы" повторы имеют в пределах 3% значений. Все остальные уникальны и их уникальность важна для анализа. Т.е. например, одна группа называется "Реклама, маркетинг и PR", другая "Реклама, маркетинг, интернет" - и первая у меня попадет в категорию "PR", а вторая - в категорию "Интернет" (естессно они обе попадут в категории "реклама" и "маркетинг"). И вот по большей части полностью повторяются только названия из 1 слова - их бывает до 10-20 копий одинаковых. Названия из 2 слов - могут иметь 1-2 копии. Все остальные - абсолютно уникальны, их нормализовать будет куда более сложной задачей, чем слить все базы в одну.

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

Сообщение от Eugene-LS - Создаём отдельную таблицу «Группы» и связь по ID группы- один ко многим с таблицей «Пользователи» Таблица «Пользователи» : - Поле ссылка на пользователя – IMHO НЕ НУЖНА т.к. може сформировать автоматом по ID Ссылка = “https://vk.com/id” & [UserID] - пользователь не может принадлежать разным группам … - Название группы – вынесено отдельно (оставляем только её ID) – и тут у меня вопрос – а вдруг пользователь может принадлежать к разным группам? - С полем «Подписчики» - совсем не понятно – их же несколько – так там Многие – ко многим – через промежуточную …. (и возможно в отдельном файле))

да, поля "Ссылка на пользователя", "Статус" и либо "Id группы", либо Ссылка на группу (одно из двух) можно удалить - они не принципиальны для моих задач.
Пользователь может принадлежать разным группам. Максимально у 1 пользователя может быть порядка 1200 - 1500 групп.
Группа может принадлежать разным пользователям. В среднем у групп либо 1 пользователь, либо 3-8
Подписчики - уникальная цифра для каждой группы.
Название группы - это самое важное поле, ради него весь борщ варится)

Но поудалять столбцы попробую, да.

0

Ну тогда связка "Пользователи" - "Группы" через промежуточную "Группы пользователей".
Так:
"Пользователи" -> Один ко многим -> "Группы Пользователей"
"Группы"-> Один ко многим -> "Группы Пользователей"
В таблице "Группы Пользователей" всего 2 поля :
[ID Пользователя] и [ID Группы] - будет компактно

0

Сообщение от Eugene-LS Ну тогда связка "Пользователи" - "Группы" через промежуточную "Группы пользователей". Так: "Пользователи" -> Один ко многим -> "Группы Пользователей" "Группы"-> Один ко многим -> "Группы Пользователей" В таблице "Группы Пользователей" всего 2 поля : [ID Пользователя] и [ID Группы] - будет компактно

Мысль поняла, попробую ее переварить и перекомпоновать базы.

Спасибо!

0

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

0

Сообщение от PuhKMV Я правда ни когда с такими большими объемами данных не работал, но возникла одна вполне сумасшедшая мысля.

У меня они по сути так все и связаны с одной БД как ссылки на таблицы. Поэтому если создать одну таблицу-справочник (по id пользователей или id групп), а остальные данные подтягивать уже из этих файлов - это решит мою задачу "Не дублировать каждый запрос по 6 раз".

А нормализовать то, что там можно нормализовать - попробую, да. Я - человек Экселя, привыкла все видеть табличками и матрицами данных. А тут действительно надо сначала оптимизировать структуру БД. Буду учиться) Спасибо!

0

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

Не, ну это плохой совет. Это как человеку, купившему швейную машинку, но сетующему, что еще не успел научиться на ней строчить, советовать "да и не строчите, шейте как раньше, иголкой".

Если уж инструмент более мощный есть - все-таки есть смысл держать курс на его освоение. Оно того стоит.

0

Сообщение от texnik-san Если уж инструмент более мощный есть - все-таки есть смысл держать курс на его освоение. Оно того стоит.

Мне сначала нужны вообще азы синтаксиса запросов. Потому что я могу написать select .. where ... group by ... left join... , но где какие скобочки и точки с запятой ставить - для меня уже темный лес, и с каждым новым языком запросов в голове все больше каша. Вот начинать надо с этого. На курсы я уже записалась.

0

Сообщение от compin ...Поэтому если создать одну таблицу-справочник (по id пользователей или id групп), а остальные данные подтягивать...

Я немного не про это.
Создавать общую табличку не нужно, общей табличкой будет запрос, объединяющий ВСЕ эти ссылки на другие базы.
Это по сути таже табличка, но витруальная.
Потом когда добавится еще одна БД, просто закините ее ссылку в общую БД и добавите ее в запрос и опять дальше работаете.
А все второстепенные и специальные запросы делаете по основному запросу как будь то это 1 основная таблица.
Почему и предположил. что нужно будет еще поле счетчика.
в первой записи с 1 до 200000
во второй с 200001 по 400000
и т. п.
Их можно будет связать связями.

0

Если нельзя обойтись просто ссылками на табл Excel, то я бы разрезал этого монстра на 7 столбцов, разделил по разным базам и потом объединил бы все коды в одной таблице даже пусть и восьмой базы(не обязат)

Вложения

	example.xlsx (10.1 Кб, 3 просмотров)
	example2.xlsx (8.4 Кб, 2 просмотров)
	example1.xlsx (8.2 Кб, 2 просмотров)
	example3.xlsx (8.3 Кб, 2 просмотров)
	example4.xlsx (8.5 Кб, 2 просмотров)
	example5.xlsx (8.1 Кб, 2 просмотров)
	example6.xlsx (8.2 Кб, 2 просмотров)
	example7.xlsx (8.1 Кб, 3 просмотров)
	Гб2.rar (27.2 Кб, 2 просмотров)
	Гб21.rar (17.5 Кб, 2 просмотров)
	Гб22.rar (19.5 Кб, 2 просмотров)
	Гб23.rar (19.9 Кб, 2 просмотров)
	Гб24.rar (20.0 Кб, 2 просмотров)
	Гб25.rar (19.1 Кб, 2 просмотров)
	Гб26.rar (19.3 Кб, 2 просмотров)

0

лдо
Гб27.rar

0

Сообщение от texnik-san Не, ну это плохой совет.

судя по отсутствию "+1спасибо", здесь все советы плохие.

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

Сообщение от texnik-san Это как человеку, купившему швейную машинку, но сетующему, что еще не успел научиться на ней строчить, советовать "да и не строчите, шейте как раньше, иголкой".

чушь, я прекрасно пишу запросы в Акцесс, когда таблицы мои на sql-сервере, что там, что тут один и тот же почти SQL. Если вести речь о преимуществах, то надо говорить о триггерах или индексах или правах доступа например, но не о запросах, разницы в запросах практически нет.

1

alvk, 1) У сервера возможности все же побогаче, есть встроенные средства делать запросом то, для чего на аксес нужны самописные функции. Одни запосы For XML уже дорогого стоят. Думаю, Галина бы их оценила - можно одним запросом текст html-странички получить.

2) Не только, есть и другие преимущества. Если сохранить запрос непосредственно на сервере в виде хранимой процедуры - то при компиляции строится план ее выполнения, оптимизирует и хранится готовый, и потому выполняется она быстрее. Запрос, передаваемый серверу из аксес - тратится время на его разбор и построение плана.

0

Сообщение от texnik-san У сервера возможности все же побогаче

разве я утверждал обратное?

Сообщение от texnik-san оптимизирует и хранится готовый, и потому выполняется она быстрее.

во-первых тут от задачи, во-вторых быстрее на сколько? вот у меня запрос выполняется за 3,5 секунды, к примеру, мне критично это "быстрее", как вы думаете?

0

можно одним запросом текст html-странички получить

я предпочитаю формировать запросы и отчеты (в НТМ-формате) программно
когда некий кусок кода регулярно повторяется -- выделяю его в функцию

0