Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

EDBEngineError

Страницы: 1 2 3 4 5 >
Climber © (2006-10-09 06:37:00)
Где фиксить EDBEngineError "Temporary table resourse limit"?.
Спасибо.

Jeer (2006-11-13 11:00:00) [1]

> Anatoly Podgoretsky © (13.11.06 10:23) [88]

Главное - чтобы не физическая.:)
Ладно, замнем-с тему.
Каждый уяснил что-то важное для себя и то - хлеб.

Anatoly Podgoretsky (2006-11-13 10:23:00) [2]
Jeer © (13.11.06 09:54) [87]
Ты не понял, у тебя просто логическая ошибка получилась

Jeer (2006-11-13 09:54:00) [3]
Anatoly Podgoretsky © (10.11.06 20:28) [86]

> А вывод?

Вывод простой - ни на одном из выполненных мной проектов, где использовались ИК, число полей и длина записи не достигали и 1/10 того, что обсуждалось по сабжу, соответственно и проблем с такими объемам не возникало.

Anatoly Podgoretsky (2006-11-10 20:28:00) [4]
> Jeer (10.11.2006 17:02:08) [68]

А вывод?
У тебя искуственные ключи, тогда согласно элементарной логике, выходит что их надо выбросить, или у меня неполадки с логикой?

Jeer (2006-11-10 18:34:00) [5]
ANB © (10.11.06 18:08) [83]

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

Jeer (2006-11-10 18:32:00) [6]

> Игорь Шевченко © (10.11.06 18:04) [82]

> менее чем за десять лет

Игорь, окстись - какие десять лет:))))
Кушать хочется и им и нам.

Важно направить поток сознания и зависящие от него финансы в очень правильное русло - ни месяца без update:))

А если ежемесячно выполнять правильные, с точки зрения разработчика и совершенное необходимые, с точки зрения Заказчика, порой даже Пользователя - update, мы легко вынырнем с конкретным проектом за пределы допустимой нам свыше жизни.

В общем, дела нас переживут:))

ANB (2006-11-10 18:08:00) [7]

> По опыту работы с оракловым лоадером проблем не наблюдал,
> не надеюсь их наблюдать и в дальнейшем.

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

Игорь Шевченко (2006-11-10 18:04:00) [8]
ANB © (10.11.06 17:46) [80]

Странно. По опыту работы с оракловым лоадером проблем не наблюдал, не надеюсь их наблюдать и в дальнейшем.

Jeer © (10.11.06 17:51) [81]

> изначальная "сверхоптимизация" базы при ее проектировании
> - задача для меня всегда первостепенная.

Как показывает опыт, любая сверхоптимизированная схема базы данных менее чем за десять лет перестает быть таковой.

Jeer (2006-11-10 17:51:00) [9]
Игорь Шевченко © (10.11.06 17:43) [79]

Решил - так решил.:)
По крайней мере я буду учитывать в дальнейшем такие проблемы, хотя и не нарывался в лоб, поскольку изначальная "сверхоптимизация" базы при ее проектировании - задача для меня всегда первостепенная.

В общем:
"Как прыгнешь, так и приземлишься". (С)

ANB (2006-11-10 17:46:00) [10]

> например выгрузку с минимальными преобразованиями в набор
> плоских файлов и запуск штатного загрузчика СУБД

граблей не оберешься. Проверено по опыту работы с оракловым лоадером.

Игорь Шевченко (2006-11-10 17:43:00) [11]
ANB © (10.11.06 17:26) [75]
Jeer © (10.11.06 17:30) [77]

Я вообще-то проблему решил :) Об чем писал в посте [45].

Вкратце все-таки попытаюсь озвучить проблему: есть база данных с несовсем идеальной структурой. Ищется наиболее быстрый способпреобразования ейных данных в почти идеальную структуру. Данных много.

Преобразование должно запустить один раз, отработать и забыть.

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

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

Jeer (2006-11-10 17:31:00) [12]

> потому что всякий autoincrement есть зло,

Согласен на все сто:)

Jeer (2006-11-10 17:30:00) [13]
Игорь Шевченко © (10.11.06 17:23) [72]

Ара, говорим -да:)))

>Я НЕ ВИДЕЛ В ДОКУМЕНТАЦИИ К BDE
..
> РЕЗУЛЬТАТЫ ПРОИЗВОЛЬНОГО ЗАПРОСА

А экстраполировать ограничения BDE на естественное и такое жеограничение временных таблиц ?

Игорь, да чес слово - тоже пытаюсь помочь тебе.
Что ж я от нефиг делать перелопачиваю уйму байтов на диске ?
Самому стало интересно, кое-какие "просветы" возникают, но до выяснения
обстоятельств умолчу.

Но попутно "всплывают образы, как у истинного левши" :)))

ANB (2006-11-10 17:28:00) [14]

> естественные ключи я до сих пор продолжаю отстаивать, потому
> что всякий autoincrement есть зло,

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

ANB (2006-11-10 17:26:00) [15]

> Игорь Шевченко © (10.11.06 17:23) [72]

dbExpress-овский компонент попробовал, который я тестил ?
Совет - блобы тянуть по одному и тут же чистить.

Игорь Шевченко (2006-11-10 17:25:00) [16]
Jeer © (10.11.06 17:02) [68]

Вдогонку: кстати, естественные ключи я до сих пор продолжаю отстаивать, потому что всякий autoincrement есть зло, порочащее реляционную теорию, хотя в ряде случаев без него трудно обойтись без существенного усложнения схемы базы данных.

ANB (2006-11-10 17:24:00) [17]

> Попытка получить доступ к max(id),

Я так извращался на клиппере. Не сказать, чтобы я был в восторге от этого. Посему, когда начал работать с ораклом и узнал про сиквенсы, меня это сильно порадовало и к клипперу я более не вертаюсь :)

Игорь Шевченко (2006-11-10 17:23:00) [18]
Jeer © (10.11.06 17:02) [68]

Вот чем мне нравится этот сайт - это посетителями. Честное слово. За те четыре года, что я здесь нахожусь, я успел познакомиться с таким количеством уважаемых мною людей, с которым в реальной жизни вряд ли успел бы пообщаться на столь разнообразные темы.

Сергей, ну скажи мне ради Аллаха всемилосердного, причем тут искусственные или естественные ключи ? Я в одном из постов написал, как выглядит запрос, никаких ключей там в принципе не используется, проблема не на сервере, проблема на клиентской стороне, не получилось у BDE справиться с таким объемом данных, данная ошибка присутствует в гугле, куда я посмотрел прежде чем задавать вопрос на этом сайте, разумеется, я испробовал все советы, которые нашел по данному вопросу, ни один не помог (хотя, там и не было обещано, что они помогут во всех ситуациях).

Я уже писал, что я не собираюсь разделять запрос на порции, в данном случае эта моя принципиальная позиция. Ключи к этой позиции не имеют никакого отношения.
Я НЕ ВИДЕЛ В ДОКУМЕНТАЦИИ К BDE, IBX НИ ОДНОЙ ФРАЗЫ О ТОМ, ЧТО РЕЗУЛЬТАТЫ ПРОИЗВОЛЬНОГО ЗАПРОСА НЕ МОГУТ БЫТЬ ПРОЧИТАНЫ ИЗ-ЗА КАКИХ-ТО ОГРАНИЧЕНИЙ.

Может, я невнимательно читал, в таком случае просьба ткнуть меня носом в документацию, я с благодарностью приму пинок и пойму, что зря ориентировался на BDE с самого начала.

Jeer (2006-11-10 17:21:00) [19]
ANB © (10.11.06 17:05) [70]

Если кто не знаком с СУБД DBISAM - напомню: создавалась как F/S ISAM, затем выросла в C/S.
Последней я практически не пользовался, т.к. имел лицензию от www.elevatesoftware.com на распространение исключительно F/S.
Там много чего вкусного по состоянию на 98 год было, BDE и не снилось такое.
Например, почти полное покрытие SQL-92.

А автоинкремент не приемлю в принципе, хотя она и позволяет.

Поэтому была сделана система конкурентной вставки очередной записи в многопользовательской среде.
Никто же не возражает, что в сети Ethernet принципиально заложены коллизии при доступе ?

Вот так и там. Попытка получить доступ к max(id), корректная отработка исключений.
По такой технологии было выполнено достаточно проектов, чтобы судить о приемлимости такого решения.

ANB (2006-11-10 17:05:00) [20]

> Не поверишь, но даже без такой возможности, все возможно.

Могет быть. Но в мс скл стандартно ID после вставки вытаскивают. Да еще и извращенно. А для доставания до вставки - нужно уже еще сильнее извращаться (наверное).

Страницы: 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »