24 May
2014
24 May
'14
11:19 a.m.
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
--
Marc Delisle | phpMyAdmin
24 May
24 May
12:03 p.m.
On Sat, May 24, 2014 at 7:49 PM, Marc Delisle <marc(a)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
--
Marc Delisle | phpMyAdmin
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
12:54 p.m.
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>> 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").
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.
--
Marc Delisle | phpMyAdmin
1:16 p.m.
On Sat, May 24, 2014 at 9:24 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-05-24 11:03, Smita a écrit :
definition tried to add we just show the column name (with defination)
already exist?
Another example is "phone_number"; which is reused in the customer table
On Sat, May 24, 2014 at 7:49 PM, Marc Delisle <marc(a)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
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.
--
Marc Delisle | phpMyAdmin
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
1:55 p.m.
Le 2014-05-24 12:16, Smita a écrit :
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 :
Yes; eventually I guess that in your project, there will be a way to
directly view the central list and change column definitions.
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?
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.
--
Marc Delisle | phpMyAdmin
3:23 p.m.
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-05-24 12:16, Smita a écrit :
this
view
complete list of columns and edit some if they want.
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 :
table:
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
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 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.
Yeah, I need to make a page to manage central columns, there users can 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.
--
Marc Delisle | phpMyAdmin
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
25 May
25 May
7:48 a.m.
On Sat, May 24, 2014 at 11:53 PM, Smita <kumarismita62(a)gmail.com> wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc(a)infomarc.info> wrote:
I redesigned the database as discussed. I completed the adding
columns
part but I got stuck when came to deletion. I have a question.
Let say I have two tables tbl1 and tbl2, both table has a common column
name "phone_number". So If user selects both tables and asks to add unique
columns to central list, then we are gonna add just one "phone_number" ,
let say we add the column/definition "phone_number" from tbl1. now let say
user select tbl2 and ask to remove columns from central list. What should
it do ? should it remove the column "phone_number" from central list or not
? as "phone_number" was added from tbl1. but "phone_number" exists in
tbl2
as well.
- Smita
--
Le 2014-05-24 12:16, Smita a écrit :
this
view
complete list of columns and edit some if they want.
>
> > 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.
>
>
> Hi Marc,
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 :
table:
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 > 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 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.
Yeah, I need to make a page to manage central columns, there users can Marc Delisle |
phpMyAdmin
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
8:45 a.m.
Le 2014-05-25 06:48, Smita a écrit :
On Sat, May 24, 2014 at 11:53 PM, Smita <kumarismita62(a)gmail.com
<mailto:kumarismita62@gmail.com>> wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2014-05-24 12:16, Smita a écrit :
I say we should remove it from the central list. It's up to the user, to
use the feature in a correct way.
Anyway, say the user added phone_number in tbl3 but never used any
central column option on tbl3. phpMyAdmin won't know that this
phone_number in tbl3 possibly has a different definition, unless there
is an option to manually validate all the tables against the central list.
--
Marc Delisle | phpMyAdmin
On Sat, May 24, 2014 at 9:24 PM, Marc Delisle
<marc(a)infomarc.info
<mailto:marc@infomarc.info>
<mailto: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(a)infomarc.info <mailto:marc@infomarc.info>
<mailto:marc@infomarc.info
<mailto:marc@infomarc.info>>
> <mailto: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
another
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 column
> "id integer(20) not null auto_increment" ? If we don't
allow then
we can
"id" (but this
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 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.
Yeah, I need to make a page to manage central columns, there users
can view complete list of columns and edit some if they want.
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.
Hi Marc,
I redesigned the database as discussed. I completed the adding columns
part but I got stuck when came to deletion. I have a question.
Let say I have two tables tbl1 and tbl2, both table has a common column
name "phone_number". So If user selects both tables and asks to add
unique columns to central list, then we are gonna add just one
"phone_number" , let say we add the column/definition "phone_number"
from tbl1. now let say user select tbl2 and ask to remove columns from
central list. What should it do ? should it remove the column
"phone_number" from central list or not ? as "phone_number" was
added
from tbl1. but "phone_number" exists in tbl2 as well.
- Smita
10:27 a.m.
On Sun, May 25, 2014 at 5:15 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-05-25 06:48, Smita a écrit :
another
> So
We'll allow only unique column name. If same column name with
way to
On Sat, May 24, 2014 at 11:53 PM, Smita <kumarismita62(a)gmail.com
<mailto:kumarismita62@gmail.com>> wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2014-05-24 12:16, Smita a écrit :
>
<mailto:marc@infomarc.info <mailto:marc@infomarc.info>>>
wrote:
On Sat, May 24, 2014 at 9:24 PM, Marc Delisle
<marc(a)infomarc.info
<mailto:marc@infomarc.info
<marc(a)infomarc.info <mailto:marc@infomarc.info
> Hi Smita,
> I have a doubt, looking at the structure you chose for this
table:
db.
<mailto:marc@infomarc.info
<mailto:marc@infomarc.info> >
<mailto:marc@infomarc.info <mailto:marc@infomarc.info>
<mailto:marc@infomarc.info <mailto:marc@infomarc.info>>>> wrote:
> 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 >
> > 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 column
> "id integer(20) not null auto_increment" ? If we don't
allow then
we can
"id" (but this
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 choice of name would be problematic, of
course; a better
choice would be
> "customer_id").
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 directly view the central list and change
column definitions.
Yeah, I need to make a page to manage central columns, there users
can view complete list of columns and edit some if they want.
I say we should remove it from the central list. It's up to the user, to
use the feature in a correct way.
Yeah, agree.
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.
Hi Marc,
I redesigned the database as discussed. I completed the adding columns
part but I got stuck when came to deletion. I have a question.
Let say I have two tables tbl1 and tbl2, both table has a common column
name "phone_number". So If user selects both tables and asks to add
unique columns to central list, then we are gonna add just one
"phone_number" , let say we add the column/definition "phone_number"
from tbl1. now let say user select tbl2 and ask to remove columns from
central list. What should it do ? should it remove the column
"phone_number" from central list or not ? as "phone_number" was
added
from tbl1. but "phone_number" exists in tbl2 as well.
- Smita Anyway, say the user added phone_number in tbl3 but
never used any
central column option on tbl3. phpMyAdmin won't know that this
phone_number in tbl3 possibly has a different definition, unless there
is an option to manually validate all the tables against the central list.
While adding new columns in tbl3, user could have used the central list to
add the "phone_number" column, that way he wont end up writing wrong
name/definition. But Yes, validating table against central list is another
option that we can add . And can be applied to existing columns in the
system and also to those that have not been added through PMA UI.
--
Marc Delisle | phpMyAdmin
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
3758
days inactive
3759
days old
8 comments
2 participants
participants (2)
-
Marc Delisle -
Smita