[development] Referential integrity -- finally?

[Earnest Berry III]

I'm planning on handling the MS-SQL port; I agree, the create DML 
functions should be created.....but SQL should be left to the user. I 
know we're always trying to get new/more developers. But, if the 
information that a "newbie" needs from the database requires a complex 
query, the either:

A) Need to be adapt enough at programming to use simple SQL statements 
and application logic to produce the
desired results (this will then prob. be refactored by the community 
after having a look at it, and some nice person
will write the complex query for them)
B) Contact someone for help
C) If they are not adapt at programming, then they can't really create a 
module in the first place, and that is a whole
other issue.

So yes, we want more people and s short learning curent, which I believe 
is there. I think this talk is for people who want to better maintain 
their modules (DB wise), support more DB's, and still offer the fine SQL 
control for optimization for advanced queries/statements/etc.

We should prob. start to come up with some standards for naming during 
creations, etc.
Example, if I do a db_create_table(array('col1' => array('type' => 
'number'), 'options' => array('index' => array('col1')))));
// Creates a table with a column col1 with an index
The index should be called 'idx_col1' (naming convention index = idx). 
so that when other DML statements happen, we're accessing the same 
index/PK/FK names across DB's.

So, I'll start:
indexs = idx_[col_name1]_[col_name2]_[...]
Primary Key = PK
FK = FK_[parent_col]_[child_col]_[..]

Good idea/bad idea?

adrian rossouw wrote:
>
> On 24 Jan 2007, at 5:20 PM, Dries Buytaert wrote:
>
>>
>> The 'database scheme definition' vs 'standard query language' (or 
>> 'data manipulation language') argument make sense to me -- although 
>> it would be great if you had pointers to references.
>>
>>
>> Either way, I'm willing to reverse my position on creating database 
>> abstraction functions for create or altering SQL tables -- but not to 
>> build SELECT/UPDATE/INSERT queries.
>>
>
> Great news.
>
> Perhaps we should contact the people handling the different DBMS ports. ?
>
> Also, this might make sqllite more easily implemented. I believe it 
> doesn't even have an alter mechanism, and
> you need to use application code to recreate tables and the 
> like. http://code.jenseng.com/db/
>
>