Le 2014-05-24 12:16, Smita a écrit :
On Sat, May 24, 2014 at 9:24 PM, Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info> wrote:
Le 2014-05-24 11:03, Smita a écrit : > > > On Sat, May 24, 2014 at 7:49 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info> > <mailto:marc@infomarc.info <mailto:marc@infomarc.info>>> wrote: > > Hi Smita, > I have a doubt, looking at the structure you chose for this table: > db_name > column_list > > This structure implies that, for any change, you have to load a > potentially big row, decode it and encode it. Imagine that there are > hundreds or thousands of column definitions for this db. > > I suggest something like: > > db_name > column_name > column_attributes > > Yeah, agree. Thanks, It would be better to keep this. :-). > I have a question: If we have "id interger(11) not null auto_increment" > already existing in central list, should we allow to add another column > "id integer(20) not null auto_increment" ? If we don't allow then we can > also keep structure like maybe: > db_name > column_name > column_type > column_collation > column_isNull > column_extra > > - Smita > In a central list, there should be only one column named "id" (but this choice of name would be problematic, of course; a better choice would be "customer_id").
So We'll allow only unique column name. If same column name with different definition tried to add we just show the column name (with defination) already exist?
Yes; eventually I guess that in your project, there will be a way to directly view the central list and change column definitions.
Another example is "phone_number"; which is reused in the customer table and in the salesperson table. You might want to always use CHAR(25) for phone numbers. So it's a good idea to split the attributes into separate columns like in your example. The default value could be there too.
Ok, thanks. We'll keep default as well.