Dane nie muszą być w jednym wierszu, żeby je czytać językiem SQL.

Dzisiaj - ciekawostka, nie-narzędziowa, ale, jak najbardziej, techniczna!

SQL rządzi!

Zainspirowany tematem
http://www.goldenline.pl/forum/2815466/sortowanie-raportow-tekstowych
(dostęp ograniczony)

Jak, z czegoś takiego (i to w pliku tekstowym):
Klucz1
10
Klucz2
20
Klucz3
30
-----------------------------------------
Klucz4
40

zrobić tabelę?:
Klucz1,10
Klucz2,20
Klucz3,30
Klucz4,40

Zrobiłem SPECJALNY przykład i filmik na ten temat.

Otóż - da się! A sam myślałem, że nie. Trzeba tylko zrobić    
parę sztuczek, a konkretnie dwie:

1. Przenieść tekst do jakiejś bazy, która umożliwi tzw.    
autoinkrementację, czyli powstanie pola numeru wiersza, który    
automatycznie ponumeruje nam wiersze, tworząc klucz unikalny dla    
tabeli, która go nie ma (trudno wymagać od pliku tekstowego, żeby    
miał taki klucz).

2. Złączyć tabelę z nią samą(!) po sprzężeniu    
alias1.ID=alias2.ID-1. Alias1 i alias2 to ta sama tabela!

Film:
http://afin.net/webcasts/HowTo_ReadTheNextLineFromTxtFile.swf

I, oczywiście, dla maniaków - SQL:
SELECT [Alias1.PoleTekstowe] AS [Klucz], [Alias2.PoleTekstowe] AS [Wartosc]    
FROM MyTable Alias1 RIGHT OUTER JOIN MyTable Alias2 ON    
Alias1.ID=Alias2.ID-1
WHERE [Alias1.PoleTekstowe] LIKE 'Klucz%'

P.S.
Zrobiłem testy (dokładnie tego samego modelu) dla nieco większej ilości rekordów:
Ilość wierszy tekstu: 7.983.360, czyli (prawie) 8 mln.
Czas ogólny: 196,39s

Ciekawe są czasy cząstkowe:
Proste załadowanie tekst->Access: 29s
Wstawienie do tabeli z autoinkrementacją: 81s
Połączenie tabeli joinem z nią samą: 81s
Reszta jest nieistotna.