On 18 Apr 19:24, Mats Gefvert wrote:
> > * MySQL: If you want to store more text (and more XML) that the
> > capacity of the textfield (64KB)
>
> I would suggest a LONGTEXT, then. 4GB should be enough for any article
> :)
Oracle can't do this AFAIK. And as already mentioned BLOBs are searchable
then.
> * I'm not particularly fond of the idea of a linked list. I see a
> tremendous potential for faulty links, i.e. database corruption.
No more corruption than usual - if we are using transaction, what we will
do.
> Furthermore, in terms of code, I cringe at the implementation details...
> :)
I don't. The DAOs are not complicated.
> I would much rather appreciate the idea of a single record per node,
> containing the article itself.
Article has meta data, permissions etc. Why splitting it then?
> My feeling is that if there's a database that can't handle arbitrarily
> sized BLOB fields, then get rid of it. (I may be overly pragmatic,
> though.) It adds unnecessary complexity for little gain.
Strange idea.
> * If it's at all possible to do (in terms of database portability), then
> I would suggest breaking out the article itself from cowiki_node and put
> it entirely in cowiki_node_spill.
cowiki_node_spill is for eg. an article that is 140 KB large. If we are
using MySQL, one part (1-64KB) is saved is in the cowiki_node, the second
part (the content and summary only, 65KB-128KB) is saved in a spill record
and linked, the third part (129KB-140KB) too. We have three records then.
No problem for the DAO to fetch the data records (three of the in this cas)
or split a text into the right chunks before saving, as the storage
abstraction class reports the maximum size of text capacity for the current
RDBMS (StorageMySQL::getTextCapacity()).
In case of Oracle where we could store only 4KB, the 140KB text will be
splitted into 140/4 records.
> * If we're already in the process of breaking out data from the node
> table, why not add a Content_Type field and make it a placeholder for
> any kind of information? JPEG and GIF files come to mind; that would be
> a neat place to store embedded information, and by putting it in the
> node file, we would already reap huge benefits from the directory/rights
> infrastructure already in place. Embedding a Content_Type field ensures
> that you could put anything in there (perhaps restricted by
> configuration) ... even up to entire DVD movies :). We use a similar
> variation in our company's flagship product and it's worked incredibly
> smoothly so far: all the web server has to do when serving the item is
> to output "Content-Type: <value>" in the header.
NO! Do not put binary data into the database, it makes no sense. This is the
worst thing you can do with relational databases - they have been not
designed for holding binary data that can be stored in the filesystem.
Meta information about a record (a JPEG eg), yes, the data itself, never!
regards dtg
|
