what drove me to store it that way was more of a performance issue. So if I store a documentID and then have a seperate table names, to_field I will have to store the username/groupname as such to_field: documentID username docuementID groupname docuementID usernamename ... based on that it seems that to read (Which occurs a lot more than writing) a document I will have to go an find all the rows with documentID in the to field and then cat them somehow and then return the whole document. Even with an index built on the documentID of the to field, it seems to be resource intensive (correct me if I am wrong). Even if I were to do this, I would still have to check the constraints by hand (since the entry can either be a username or a groupname (and if its a group, the user has to belong to that group). So coming back to the original synopsis. Is there a way I can just send the whole document to a stored procedure and then the stored procedure takes the text component of it and tokenizes it and then I do constraint checks on it? thanks. -assad On 1/11/06, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Assad Jarrahian <jarraa@xxxxxxxxx> writes: > > A column of type text contains username's and groupname's followed > > by comma (eg. 'jarraa, mooreg3, keith') [it is stored this way > > because it will be displayed in this format]. > > You should *not* allow display concerns to drive your database layout. > The pain you are now experiencing is just the first taste of why that's > a bad idea. > > Store the usernames and groupnames separately. If you have an > application that's too dumb to concatenate them for itself, you > can make a view on the table that provides the display representation > the application needs. > > regards, tom lane >
