Структура БД

Работа VB и СУБД (Access, MSSQL, MySQL, Oracle и пр.)
Правила форума
При создании новой темы не забывайте указывать используемую СУБД.
SLIM
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1840
Зарегистрирован: 04.04.2008 (Пт) 18:21
Откуда: Краснодар

Структура БД

Сообщение SLIM » 19.12.2009 (Сб) 20:34

Существует некий набор данных, имеющий структуру

Дата, КодПозиции, КодМагазина, Количество, Оборот, Остаток

Ну, всем давно известная структура, магазин например такую как правило имеет.
Это довольно большая база за год в моей фирме (порядка 10ТРб).Есть серия неких запросов, они однотипные и, в основном, только на выборку. Но выбирать с такой базы не очень удобно, при таких условиях. Поэтому я решил выгружать данные предварительно в другую табличку, и уже оттуда отбирать (что повысит скорость, не будет тормозить сервер, так как таких запросов может быть до 30 в день).

Чтобы выгружать данные, я придумал некую систему, которая выгружает с Excel коды и даты в некие первичные таблицы
1. Коды магазинов (поля ID, Код)
2. Коды позиций (поля ID, код)
3. Даты (поля ID, ДатаСтрат, ДатаФиниш)!!!!!!!!!!!!!!
4. Справочник запросов (поля ID, Время запроса, Имя запроса, СтатусВыполнения)

После того как данные залиты, то настраивается сервер на постоянную отборку в соответствии с данными. Т.е. в job-е находится наиболее ранний запрос, узнается его ID и вытаскиваются данные.

Но вот в чем проблема. Есть у меня табличка, которая уж слишком затруднят мне жизнь. Эта табличка помечена знаками воклицания. Каждый запрос становится путанным и я не могу его оптимизировать. "Сотни" inner-ов притормаживают выполнение. Бывает гораздо проще выгрузить дату начала и дату конца в отдельные переменные и ставить условие по ним, чем цеплять табличку. Тогда зачем табличка?
Я было хотел переместить поля дат в табличку с кодами магазинов или кодам позиций, но мне показалось что это криво, хоть и удобнее юзать.

Скажите, какая самая оптимальная структура при данных условиях?
Пишите жизнь на чистовик.....переписать не удастся.....

alibek
Большой Человек
Большой Человек
 
Сообщения: 14205
Зарегистрирован: 19.04.2002 (Пт) 11:40
Откуда: Russia

Re: Структура БД

Сообщение alibek » 19.12.2009 (Сб) 22:00

Выгружать 10Тб в Excel? Это новогодняя шутка?
Lasciate ogni speranza, voi ch'entrate.

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

Re: Структура БД

Сообщение FireFenix » 19.12.2009 (Сб) 22:56

alibek писал(а):Выгружать 10Тб в Excel? Это новогодняя шутка?

Это новый вид спорта :D

Выгрузка контента за пределы СУБД будет ещё медленней чем выборка из неё..... уж лучше программно в СУБД создавать временные таблицы

SLIM писал(а):Скажите, какая самая оптимальная структура при данных условиях?

Самое оптимальное оптимизировать.... если не запросы, то строение БД или связь элементов
К примеру выделить таблицу в которой хранится дневная информация и после окончания дня - атачить к таблице архива

SLIM писал(а):Каждый запрос становится путанным и я не могу его оптимизировать. "Сотни" inner-ов притормаживают выполнение.

100 Inner Join в одном запросе?
Как показала практика - в БД выборка выполняется быстрее одним жирным запросом, чем пачка подзапросов

Опиши подробнее структуру БД и как реализуются запросы...
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる

SLIM
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1840
Зарегистрирован: 04.04.2008 (Пт) 18:21
Откуда: Краснодар

Re: Структура БД

Сообщение SLIM » 20.12.2009 (Вс) 1:00

alibek писал(а):Выгружать 10Тб в Excel? Это новогодняя шутка?

Нет конечно.

Обычно это как происходит. Отбираются в отдельную табличку записи из одной огромной и это выгружается.
Какие записи нужно выгружать известно заранее. Например сегодня может быть известно что нужно будет выгружать 05.01.2010.
Можно было бы выгружать из этой большой таблицы, но когда начинаются агригаты, сразу притормаживать начинает. По
тому агригаты лучше считать по меньшей в объеме таблице. Вот ее то я и хочу создать. И так, чтобы данные в нее выгружались постепенно и автоматически.

Это все я нагружу на job, но саму систему выгрузки продумать не могу точно.
Примерно так
1. В таблице справочников запросов отбирается запись с наименьшим ID
2. Проверяется валидность дат, т.е. есть ли что выгружать за этот период
3. Выгружаем из огромной таблицы подвязав при этом
- Таблицу с датами
- Таблицу с кодами позиций
- Таблицу с кодами магазинов
- связав три таблицы по ID и ограничив ID нашим избранным (самым ранним)
Причем если таблицы с кодам я подцеплю код-->код, то таблицу с датами я подцеплю только по ID к другим моим таблицам, что весьма запутывает. Например по проверкам, если таким образом составить запрос, но скорость раз в 15 падает чем при явном указании дат в between. Если бы например было так что даты в таблице с кодами позиций, то я просто подвязал бы по код-->код и ограничил ID...
Но это бы ничего. В пункте два придется проверять наличие данных. А тут есть отдельная таблица (чтобы не цеплять большую), в которой есть данные Код магазина, Дата. Так вот еще и там проблемы будут, так как там нужно будет левое соединение.
4. Удаляем данные из таблиц с кодами и датами данного ID
5. Ставим статус "выгружено" в справочнике запросов

FireFenix писал(а):Выгрузка контента за пределы СУБД будет ещё медленней чем выборка из неё..... уж лучше программно в СУБД создавать временные таблицы

Читать не умеешь? Я же сказал что хочу выгружать в отдельную табличку.
FireFenix писал(а):Самое оптимальное оптимизировать.... если не запросы, то строение БД или связь элементов
К примеру выделить таблицу в которой хранится дневная информация и после окончания дня - атачить к таблице архива

БД оптимизирована достаточно.
По поводу выделения таблицы, я это и хочу сделать.
Оптимизация состоит только в системе таблиц, которые я хочу сделать.
FireFenix писал(а):100 Inner Join в одном запросе?
Как показала практика - в БД выборка выполняется быстрее одним жирным запросом, чем пачка подзапросов

Я не зря взял слово "сто" в кавычки. Это образно.
Понятно что например для выборки из большой таблицы нужно
1. Одно внутреннее соединение для кодов магазинов по коду
2. Одно внутреннее для кодов позиций по коду
3. Одно внутреннее по ID
4. Еще одно внутреннее по ID скорее всего. Одно Магазины-->Коды позиций, второе Коды позиций-->даты, ну или как-то так.
Пишите жизнь на чистовик.....переписать не удастся.....


Вернуться в Базы данных

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 35

    TopList  
cron