Hi, I've made some changes in SQL backend desing, updated design is at:
http://www.stud.fit.vutbr.cz/~xhorak50/diplomathesis/files/100405_mysql_design_v2.png
As Philipp M. proposed, Representations are now provided with an SHA1,
but in a bit different way than in BDB. In BDB there is another table,
which means an unnecessary joining in SQL.
Txt_id fiels were renamed to txn_id, that was only a mistake. Txnprop_id
was removed and composed primary key <txn_id, name> is used instead.
Table names were kept in plural, even if Geoff R. supposed to use
singular, but plurals will correspond with BDB better. But if anybody
have good reasons, it's no problem to change it.
The last thing is the discussed storing of the representations in files,
not in DB. I've made a simple test of the access speed to database and
to pure filesystem, the report is here:
http://www.stud.fit.vutbr.cz/~xhorak50/diplomathesis/files/100406_data_access_speed_comparison.pdf
The conclusion is, that SQL can be faster when many small files are
readed the first time (thanks better cache), in other cases the
filesystem is faster, as supposed. But Greg S. had a very good point,
that I agree with:
> My gut says "not that much faster". In most scenarios, the network
> bandwidth between the client/server will be the bottleneck. Reading
> the data off a disk (rather than from a DB) is not going to make the
> WAN connection any faster.
...
> I'd go with the "store content in the database" until performance
> fiures (or a DBA) demonstrates it is a problem.
Thus the data stay in DB right now.
