Re: Modification in LiveUser SQL for Perm and Auth

From: Date: Thu, 10 Oct 2002 13:05:56 +0000
Subject: Re: Modification in LiveUser SQL for Perm and Auth
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-9993@lists.php.net to get a copy of this message
<paj@pearfr.org> wrote : > On Thu, 10 Oct 2002 14:32:28 +0200 > Bertrand Mansion <bmansion@mamasam.com> wrote: >> I would like to make some modifications in the SQL for the liveuser >> tables but they might not be backward compatibles so take this message >> as a suggestion only and tell me what you think. >> >> 1. I would prefer to use uppercase for field and table names: >> This is because I already had trouble with Oracle converting all >> names to uppercase by default, so I took the habit to uppercase >> everything. > > I prefer lower case everywhere. If you have fields in lowercase and use something like an associative fetchrow, calling $row['myfield'] won't give you the result you expect in Oracle, you will have to call $row['MYFIELD'] instead. At least, this is the last experience I had with Oracle. Maybe Thies or some Oracle experts can confirm ? > >> 6. Use varchar() instead of char() where char is not necessary. >> Varchar() takes less disk usage. > > Disk usage is not a point for me :-), is varchar suitable for *all* > rdbms we used in DB ? Disk usage should still be taken into consideration. If you look at the SQL for Perm tables, there is a char(255), the maximum size. Suppose you don't fill this field, it'll still take 255 chars. On the other hand, varchar are not interesting for small sized fields, but there are none AFAIK in the liveuser SQL. About varchar(), I think Oracle uses varchar2() instead. But these are adjustments that can be done later if needed. This is interesting: http://www.marston-home.demon.co.uk/Tony/varchar.html >> Note that I am not a DB expert, these are just habits I took which I >> found really useful on the longer run. Still, I am quite open to other >> suggestions. > > I usually like optimisations as far they do not break portability. :-) And me, I don't care about portability as long as it speeds ! :-) Kidding, portability is also a good thing but can only be achieved if we write different SQL for different databases. I don't see any other way. Bertrand Mansion Mamasam

« previous php.pear.dev (#9993) next »