On Mon, 16 Apr 2012 16:10:21 +0200, "Olaf Kluge" <olaf.kluge@...>
wrote:

> Now I have two ideas. I create a table with all fields (separate for

each

> information) and an import stored procedure fill this table with
> information
> from the long string. (line_number = substring(:str_in from 1 for 4))

etc.

>
> String: 1234A1E2WEWE3432334
>
> Into Field 1 = 1234, Field 2 = A1, Field3..
>
> Or
>
> I made a table with one field and save only the complete string in it.

In a

> second table I store the information about the field-names and the
> start-byte. If the client-visualisation gives me the start-byte, I can

get

> this information from the one table and disassemble the string from the
> other while executing. This method had the advantage, that I can simply

and

> short change the configuration if the layout of the string was changed.
>
> String: 1234A1E2WEWE3432334 into one field and get the information by
> executing the stored procedure.
>
> What can be better (performance, etc.)

Your second solution would amount to you creating a database in a
database. It also means that on every request Firebird will have to
retrieve the string as is, and then split that every time. I assume that
using Firebird as a real database and storing the data in separate fields
will yield better performance: you only need to split the data on storage
time, not on each load.

But if you want to know for certain: try both approaches and measure it,
but then you could just as well use a flatfile to store this data instead
of a database.

Mark