|
|
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Действительно,за 3 года мне такое не приходилось увидеть, но теоретически если это какая нибудь билинговая система или обработка статистики, где нибудь в центральном офисе... но я не думаю что реально понадобится 500 000, для сего тогда SQL,выборку придумали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 09:42 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
нет эту информацию потом вгружают в другую БД автоматически. по сути ето перегон инф. из одной базы в другую. Другими методами невозможно осуществить! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 10:04 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
всем спасибо! общий смысл расуждений я уловил! спасибо всем за подсказку! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 10:05 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982нет эту информацию потом вгружают в другую БД автоматически. по сути ето перегон инф. из одной базы в другую. Другими методами невозможно осуществить! тогда зачем все это тащить на клиента ? неужели средсвами серверов сделать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 11:02 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
... нельзя ? (эт я забыл добаить) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 11:03 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
нет нельзя!там структура файла сложна да и должно работать на любом ПК в сети ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 12:50 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Афтор. Может тебе лучше сходить на форум к Ораклоидам и спросить про репликацию? P.S. Засмеют ведь. С велосипедами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 13:10 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982....тоесть "данные полей сортировки" это уникальный индефикатор записи, ну в Оракле ROWID? или любое другое уникальное поле. у Вас есть список, который Вы показываете клиенту... предположим опорная запись - та, к которой привязан псевдо курсор списка... предположим с верху Вашего списка распологаются наименование полей а так-же(!) направление и порядок сортировки некоторых, выбранных полей... Тогда от опорной записи Вам необходимо те значения полей, по которым произведена сортировка (плюс некий уникальный, можно любой ID. Это служит для навигации по повторяющимся данным в полях сортировки). В сиквол запросе Вы указываете поля сортировки, условия соответствуют порядку сортировки, значения у Вас имеются (из опорной записи). Так же в сиквол запросе Вы можете попросить ВСЁ ЧТО МЕНЬШЕ, а так же ВСЁ ЧТО БОЛЬШЕ. При этом ограничить по кол-ву строк выборки. Ну предположим 200 строк. Приимущества... а) Вся работа по подготовке данных осуществляется там, где и положено - на серваке БД. б) по сети гонятся только необходимые для визуализации на клиенте данные, а не все 500 мульёнов записей. в) Клиент видит реальное положение ОН-ЛАЙН дел. Т.е. если какой то клиент удаляет в этот момент, то алгоритм честно отработает это удаление (апдэйт, вставку - не важно). минусы... 1) технология. не простая, скажем так. особенно если сиквол запрос нагружаем доп. функционалом (подсветка полей, вычисление неких логических функций, циклические ссылки в таблицах)... 2) скорость. на данный момент времени есть опыт реализации на битриве (новелл сервак) по индексным полям (и их комбинаций не так много - конечно)... и на оракле без доп. индексации... Оракл замечательно справляется с задачей. На других движках - вряд ли осуществимо, т.к. они менее мощные... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 14:39 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Приходилось мне делать аналогичную выгрузку как из Oracle так и из MSSQL. Работал через BDE, делал традиционно, перебирал все записи, можно for или while и в каждой записи перебирал все поля. Сформированную строку направлял в другую БД или в файл, можно через потоки. К полям обращаться лучше через s = s + Query1->Fields->Fields[j]->AsString, от этого зависит скорость работы. При этом скорость работы достаточно хорошая, зависит от сервера, сети и рабочей станции, чем шустрее тем лучше, проблем с перекодировкой не было. Попробовал переделать на ADO, скорость работы значительно упала, пробовал менять тип курсора, другие параметры, но прежней скорости близко так и не достиг! Махнул рукой и оставил старый вариант через BDE. Кстати в Oracle были свои способы выгрузки в текстовый файл, например SQL*Plus, после команды spool <filename>.<ext> и до set spool off, всё что буде на экране уйдёт в файл. Есть команды форматирования данных... Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 17:37 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982нет эту информацию потом вгружают в другую БД автоматически. по сути ето перегон инф. из одной базы в другую. Другими методами невозможно осуществить!Прямо таки невозможно? :) Перегон информации из одной базы в другую делается на раз-два на самом деле. Из базы источника данные выгружаются в какой-либо универсальный формат. Например csv. Потом на пачку этих csv натравливается специальный конвертор (написаный на чем угодно, хоть С, хоть Perl) который их исходных csv представляющих таблицы старого формата делает новые csv с таблицами нового формата. Потом база получатель всасывает подготовленные csv. Это если БД получатель глупая :) А если БД получатель умная, то база получатель напрямую подключается к базе источнику и обращаясь к таблицам источника как вьюшкам вытягивает и сразу конвертирует все нужные данные. Клиентов при этом вообще нету. Не нужны они для этой задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 18:17 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Если задача перетянуть большие данные из одной БД в другую, то оптимальный вариант будет такой, запрос выбирает данные с сервака, порциями перегоняет клиенту, после каждой порции происходит фиксация данных. Таким способом можно перегонять практически неограниченный объём данных. Для Oracle в SQL*Plus есть функция copy from, которая всё это делает. Пользуюсь таким способом много лет, работает очень шустро, объёмы несколько GB, записей десятки миллионов, проблем нет. Если не делать промежуточные фиксации (commit), временное пространство значительно разбухает и т.д. Если делать, что своё, разумнее использовать компоненты доступа специально заточенные под C++ и Oracle, например ODAC, процедура таже, копирование порциями... Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 23:41 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Надо открыть ридонли курсор. В ODBC это проходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 07:07 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Угу спасибо за советы! про выгрузку! понимаете иногда боссы говорят что надо проводить обмен данными между двумя орагнизациями, онимежду собой договариваются, сочиняют как будет проходить выгрузка при это о том как это лутше сделать у знающих людей не кто не спрашивает. А потом дают вам тех задание, и вы думаете как лутше сделать. И что самое интересное те кто будет принемать инф. так же сидят и думаю о том как еЁ закачть в БД. Ну всем спасибо за советы!и внимание! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 07:19 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982нет эту информацию потом вгружают в другую БД автоматически. по сути ето перегон инф. из одной базы в другую. Другими методами невозможно осуществить! Вы сами так считаете или кто-то подсказал? Во всех нормальных СУБД есть dblink, можно работать через sqlplus с csv. В любом случии такие действия на клиенте не делаются, потому как в рабочее время за такое голову сносят. ИМНО это прерогатива АБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 07:27 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
kennethr mikola1982нет эту информацию потом вгружают в другую БД автоматически. по сути ето перегон инф. из одной базы в другую. Другими методами невозможно осуществить! Вы сами так считаете или кто-то подсказал? Во всех нормальных СУБД есть dblink, можно работать через sqlplus с csv. В любом случии такие действия на клиенте не делаются, потому как в рабочее время за такое голову сносят. ИМНО это прерогатива АБД. блин ну я же писал до этого почему так надо делать! меня просто порожает! Почему все думают над условием задачи а не над решением еЁ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 07:47 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Неужели , все таки , стандартными средствами Оракла нелзя выгрузить данные с определенной структурой ??? Неповерю ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 08:28 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
JibSkeartНеужели , все таки , стандартными средствами Оракла нелзя выгрузить данные с определенной структурой ??? Неповерю ... можно но первое файл будет лежать на сервере оракла (но ето не проблема) а второе нет знаний и времени. поетому приходится делать как получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 08:36 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982можно но первое файл будет лежать на сервере оракла (но ето не проблема) а второе нет знаний и времени. поетому приходится делать как получится Тогда и огребете результат "какой получиться". 100-200 Мб для 500 тыс строк вполне нормально. Если уж так хочется создать exeшник для начала задумайтесь нужны ли вам согласованные данные. Oracle гарантирует это для одного запроса без блокировок. Можно попробовать использовать метод kolobok0 совместно с isolation_level=serializable. Иначе данные могут быть несогласованы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 09:04 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982 JibSkeartНеужели , все таки , стандартными средствами Оракла нелзя выгрузить данные с определенной структурой ??? Неповерю ... можно но первое файл будет лежать на сервере оракла (но ето не проблема) а второе нет знаний и времени. поетому приходится делать как получится Так, вам и советуют как лучше , но я бы передачу из одного сервера на другой , реализовал бы на стороне серваков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 09:18 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
JibSkeart mikola1982 JibSkeartНеужели , все таки , стандартными средствами Оракла нелзя выгрузить данные с определенной структурой ??? Неповерю ... можно но первое файл будет лежать на сервере оракла (но ето не проблема) а второе нет знаний и времени. поетому приходится делать как получится Так, вам и советуют как лучше , но я бы передачу из одного сервера на другой , реализовал бы на стороне серваков. конечно это самое простое и верное решение былобы. соглосованость данных не кретична. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 11:09 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982 JibSkeart mikola1982 JibSkeartНеужели , все таки , стандартными средствами Оракла нелзя выгрузить данные с определенной структурой ??? Неповерю ... можно но первое файл будет лежать на сервере оракла (но ето не проблема) а второе нет знаний и времени. поетому приходится делать как получится Так, вам и советуют как лучше , но я бы передачу из одного сервера на другой , реализовал бы на стороне серваков. конечно это самое простое и верное решение былобы. соглосованость данных не кретична. "было бы" ??? Мешает только отсутвие знаний ? и это вас остановило ? ай-ай-ай ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 11:11 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
JibSkeart "было бы" ??? Мешает только отсутвие знаний ? и это вас остановило ? ай-ай-ай ! нет останавливает нехватка времени и самое главное бумашка именуема "Соглашением"в которой описан формат выгружаемого файла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 11:23 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Хе-хе ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 11:50 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
mikola1982 нет останавливает нехватка времени и самое главное бумашка именуема "Соглашением"в которой описан формат выгружаемого файла. Формат, надеюсь, текстовый? Тогда в Oracle решается на раз-два на стороне сервера. Вопрос, конечно, не в этот форум, но примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Этот текст можно выполнить: -- в sqlplus; -- любым компонентом, к-рый позволяет выполнить произвольный DML, -- (ИМХО, самое правильное) оформить в виде ХП и запускать одним из указанных способов. PS: Чтобы разрешить Ораклу писать в 'MyPath' нужно в init.ora добавить параметр utl_file_dir с соотв. значением. PPS: UTL_FILE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 13:42 |
|
||
|
Работа с большими таблицами
|
|||
|---|---|---|---|
|
#18+
Goldminer mikola1982 нет останавливает нехватка времени и самое главное бумашка именуема "Соглашением"в которой описан формат выгружаемого файла. Формат, надеюсь, текстовый? Тогда в Oracle решается на раз-два на стороне сервера. Вопрос, конечно, не в этот форум, но примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Этот текст можно выполнить: -- в sqlplus; -- любым компонентом, к-рый позволяет выполнить произвольный DML, -- (ИМХО, самое правильное) оформить в виде ХП и запускать одним из указанных способов. PS: Чтобы разрешить Ораклу писать в 'MyPath' нужно в init.ora добавить параметр utl_file_dir с соотв. значением. PPS: UTL_FILE РЕСПЕКТ тебе и уважуха! Давно ето искал! Спаисбо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 13:57 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=34179736&tid=2029891]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 494ms |

| 0 / 0 |
