On Mon, 16 Apr 2012 16:10:21 +0200, "Olaf Kluge" <[email protected]> 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
