Хм!... TTable ( CBuilder/Delphi -> RecordSets

Здравейте колеги,
Имам една камара DBF-та. Имате ли наблюдения от вашата практика,
дали при опрделено нарастване на броя на записите, TTable става неефективна
за използуване. Имам ситуации в коитo много-много не ми се работи
с TQuery - UpdateSQL.

Поздрави: Любо

Преди време май пак чепкахме въпроса за DBF и SQL. Ето какво мога да споделя от личен опит. Работя с няколко мандрички. Най-голямата от тях събира мляко от около 600 човека дневно - разбирай записи. Обикновенно пазят информацията от началото на годината, значи до момента приблизително 8x30x600 записа в основния файл с данни. До тази пролет програмите бяха клиперски, но сега ги прехвърлих на Delphi. За сега не са зябелязани проблеми, свързани с исползването на TTable и размера на файла. Алгоритмите за обработка и извличане на справки са прехвърлени от клипер почти 1:1. Не върви със същата скорост, но това е живота :(
Опитах да направя някои от справките със SQL заявки, но вървят още по-бавно. Трябва да си призная, че в SQL-a не съм с такъв опит, както в Паскала. Мисля че няма особен смисъл да се използва SQL при файлово ориентирани данни. При тях така и така държиш всичко в ръцете си, поне можеш да използваш индексите както намериш за добре.

Няма "особенна" полза от SQL при работа с DBF-та.
Аз обаче от време на време го ползувам в проста форма:

select това_онова
from еди_къдеси
where пазарлъци
order by някак_си

... поселе пускам по някой Grid за да го ГЛЕДАТ мераклийте.
Иначе входът на данни "най-консервативно" съм го поверил на
"юнашки работещи" DOS workstations. Немат лабаво. Програмите за входовете
са направени много добре, без излишни "заглеждания" по картинки и с много
голям набор от удобни контроли. Иначе казано:
"Сложни програми.... за прости логически структури".
Тъй както гледам, не се очертават файлове с повече от 50-100 000 записа.
И те са само 5-10 на брой
Мисълта ми е, че когато се подготвя информация само за "View", една
добре премерена SELECT с уместни критерии може да свърши бърза и
добра работа, особенно, когато човек малко го мързи.
Но да се тръгне "срещу DBF-та" (ха-ха) с UPDATE,INSERT,DELETE (SQL)
си е меко казано "кофти намерение". Аз буквално преди 1 час "сърбах попара".
Като едно обобщение на тези приказки:
Сетих се, че преди време някой тук изрази остро съмнение за ефективността
на TTable при "много запис". Тъй както гледам твоя пример - опасенията май
не са много основателни. Тъй че, едно-две нещица ще ги заложа на TTable.
Отвари ми се една питанка във връзка с SQL, но в другата тема.

Благодаря за показателния пример.
Поздрави: Любо

.

Ами , какво пише пише в документацията : Може един .DB ili .DBF move da ima maksimalen obem ot 2 GB , no над 300МВ могат да се появят някой стрнични ефекти, както и проблеми с индексирането .Лично аз нямам преки наблюдения .
Чао !!!

Ако някой изпадне в ситуация с файлове .DB / .DBF, чийто размер отива
в порядък гигабайт, е време да помисли за друга технология за изграждане
и обслужване на база от данни. При мен най-големите не надхвърлята
20 - 30 MB. Даже и това е твърде много. Ако човек има известен опит при
проектиране на логическите елементи в една база, той знае, че не трябва
да се "хулиганства" с разни неща, като на всеки record да има място за
"автобиография", снимка, музикално изпълнение, рецепта за "джуркан боб
по килифарски", или нещо такова. Ако все пак се налага работа в стила на
тези "екстри", там няма място много-много за .DBF.
Като майтап, давам следния пример. Знам софтуер, в който разработчика
използува индекс с ключ 90 символно поле. Просто да ти умре магарето.
Разбира се, това са редки "изцепки".
Иначе казано, имам огромно желание да коментрам една тема, която
би се наричала "Оптимизиране на логически структури в бази от данни".
Но тя е страхотно "дебела". Направо ме е страх.

Поздрави: Любо

Относно "дебелата" тема "Оптимизиране на логически структури в бази от данни", ако искаш можеш да погледнеш: [линк]

Поздрави !

и мене от тези писания, по-точно от забележките, че има проблеми с използването на CDX индекси. Дори и в най-новия вариант на BDE правят уговорката че не е зле да използваме такива индекси само read-only. За сега не съм имал проблеми - сигурно съм късметлия :) Успокоявам се, че проблемите може би възникват при размер на файловете като цитираните по-горе.

Pri iztriwane na zapisi ot tablica dBase
zapisi ostavat v faila , no se markirat kato
iztriti. dori i vsichki zapisi da iztriete
tablicata pak che ostane (primerno 10Mb)
Zatova pri dobaviane na novi zapisi (primerno 10)
SQL che se bawi znachilno.

Suvet:
Edinstwenie nachin iztritite zapisi da budat premahnati naistina ot faila triabva da se izpozva
funkciqta na BDE API /..Restruction../
(ne si spomniam tochno imeto na tazi funkcia
kato se pribera v kuchi che go vidia i che go izpratia)

В този help "C:\Program Files\Common Files\Borland Shared\BDE\bde32.hlp"
са описани всички DBEAPI + примери на Delphi и С++Builder

Това е DbiPackTable функцията която пакетира таблицата т.е. премахва наистина
изтритите записи.

function DbiPackTable(hDb: hDBIDb; hCursor: hDBICur;
pszTableName: PChar; pszDriverType:
PChar; bRegenIdxs: Bool): DBIResult stdcall;

//Пример за пакетиране на таблица

unit ...

interface
.
.
.
procedure PackTable(Table: TTable);

implementation

uses BDE;

procedure PackTable(Table: TTable);
var
Props: CURProps;
begin
if not Table.Active then
raise EDatabaseError.Create('Таблицата трябва да е отворена');

if not Table.Exclusive then
raise EDatabaseError.Create('Таблицата трябва да е отворена при Exclusive := True');

//Get the table properties to determine table type...
Check(DbiGetCursorProps(Table.Handle, Props));

if (Props.szTableType = szDBASE) then
Check(DbiPackTable(Table.DBHandle, Table.Handle, nil, szDBASE, True))
else
raise EDatabaseError.Create('Таблицата трябва да е dBASE тип');

Table.Open;
end;