Sackgesicht VIP
Total posts: 1,636
27 Jun 2012 23:37

I always had one concern with the existing database layout (beside the fact that all content of all types are stored in one table) and this is the text format which is used for all sort of data (numeric, date, decimal etc).

Maybe in a future version, as a first step, some additional "field_value" columns can be introduced. Like field_value_integer, field_value_datetime ...

In an existing setup with a parent/child combination, i made some tests.

Using around 40K records with a 1:1 relation, it takes more than 100x more time to get the result from the indexed text (longtext) field against the indexed int(11) field ....

Just an observation and another area where performance improvements can be introduced.

Last Modified: 02 Mar 2014


Guest
28 Jun 2012 01:05

It is vakuable notice as usually. The speed is very important. It seems that the deal is in these fields itself. Perhaps there is no way to accelerate it


Sergey
Total posts: 13,748
28 Jun 2012 01:35

I think it totally make sense. ALthough it will not reduce number of records in record_values. Just make some records field_value NULL. I have to check if it will impact somehow but generally it is possible. ANd if it will improve, why not :)


Sergey
Total posts: 13,748
28 Jun 2012 05:50

Do you mean to make few tables like record_values_tests, record_values_ints, record_values_dates?


Sackgesicht VIP
Total posts: 1,636
28 Jun 2012 06:21

i have not thought about it carefully .. i was thinking to keep the existing structure just some new columns in js_res_record_values...

existing field_value for text information (as it is now)

field_value_int for integer (parent/child, status ..)

field_value_datetime for date field

field_value_decimal for digits field ..

then the fields will be categorized based on field content and will just store the content in the respective column ... so the storage format will perfectly fit the field content.

Powered by Cobalt