On Sat, May 24, 2014 at 9:24 PM, Marc Delisle <marc(a)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(a)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.