I agree. I think that each table should use a single key, preferably an auto-incremented integer that has no relation to the data in the table. Requirements always change, and having a key unrelated to data insulates against that. Additionally, having compound primary keys (keys that are made from two or more columns) complicates ORM greatly. This is something I have run into in developing my own interface.
However, I understand the difficulty in changing the database layout now. I'm sure some of the fundamental changes I would like to see would require much additional coding effort throughout OpenSER, which I shouldn't start asking for until I'm able to help with coding. I would be willing to share some of my views on the database structure, and to help design an upgraded layout if any of the developers felt like it was needed and/or important at this time. ---Mike > I note that user_preferences has uuid as start of the primary key - up to > version 1.0.1 the username was the key. > > Surely I dont like to cause any offence with the developers - but wouldnt > it be preferable to have consistent key indexes across all modules for > similar functionality ? It appears that only the avpops module utilises > the uuid lookup. > > I came across this due to the serweb problems which can either use username > or uuid as key index but not both. > > Cheers > > Gerry _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
