Re: Conf: argue !

Wim Niemans ri schrieb:
> On 25 Feb 2005 at 13:52, Manuel Holtgrewe wrote:
> 
> 
>>Wim Niemans ri schrieb:
>>
>>>On 23 Feb 2005 at 0:22, Manuel Holtgrewe wrote:
>>>
>>>Config_values form a tree. Trees are hierarchies and by-default hard to 
>>>implement in a relational model because they don't adhere to that.
>>
>>Oh, they adhere perfectly. The relational model handles them well, too. 
> 
> 
> Oh please, Manuel. Give me a chance to understand what you're saying.
> You are suggesting that there is something commonly known as 'the 
> relational model'. I do know about at least 3 slightly different versions. 
> Can you explain what you mean by 'the relational model' ?

The relational model was introduced by Codd and has been further refined 
over the last years. There is a clear mathematical definition of how 
data is to be represented in a relational database.

For a full explanation about the relational model and further DB 
techniques, read Chris Date's "Introduction to Database Systems".

>>The only weak spot in the relational model is the implementation and 
>>specification of SQL: If SQL would implement the relational model, it 
>>would be easy to use, easier to implement and smell less of hacks.
>>
>>Read Fabian Pascal's "Practical Issues In Database Management" about a 
>>short but pretty complete explanation of that topic.
> 
> 
> This is definitive not the first book written on the subject. The topics 
> covered rised already in early 1970 when mr. Codd introduced SQL and the 
> relational approach of massive data. Apperently human mankind didn't 
> manage to overcome the restrictions and/or is just starting to understand 
> the full impact of his paper.

As far as I know, Codd did not introduce SQL, by the way. SQL evolved 
out of IBM's "SEQUEL".

> And...eeeh...did you notice that the proposal for the table in the draft 
> is just a complete normalization of conf_values (excluding future 
> additions offcourse) ?
> The essence of it all is that there is a key to a config_value: call it 
> path or otherwise.

I did not mean to offense you. It has just been my regular side punch at 
SQL and so called "relational databases". Sorry to confuse you.

> 
> 
>>>From current code of Conf:, method get(path):
>>>$assign='return $this->domains'."['".str_replace('/',"']['",$path)."'];";
>>>return eval($assign);
>>>
>>
>>Okay, so it seems to be simple to expand the data in the database into a 
>>PHP array tree.
> 
> 
> At the current technology level, yes, it's simple. But anybody is invited 
> to come up with a simpler or faster solution.
> And, to be honest, that we have to build a php array from it SUCKS.
> It's a restriction that is introduced by the way conf_values are handled 
> in BC.

Sorry, I do not understand you here? Why does it need to be faster? It 
should be moderately fast and if you cache it - who cares about the one 
time "compile" run?

Bests

Manuel