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
On Sat, May 24, 2014 at 7:49 PM, Marc Delisle 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
--
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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> 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_attributesYeah, 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.
On Sat, May 24, 2014 at 9:24 PM, Marc Delisle 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> 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_attributesYeah, 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
"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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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.
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle marc@infomarc.info wrote:
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 thistable:
> 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" (butthis
choice of name would be problematic, of course; a better choicewould 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 customertable
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 columnslike
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Sat, May 24, 2014 at 11:53 PM, Smita kumarismita62@gmail.com wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle marc@infomarc.info wrote:
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 thistable:
> db_name > column_list > > This structure implies that, for any change, you have to loada
> 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" (butthis
choice of name would be problematic, of course; a better choicewould 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 customertable
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 columnslike
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
--
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2014-05-25 06:48, Smita a écrit :
On Sat, May 24, 2014 at 11:53 PM, Smita <kumarismita62@gmail.com mailto:kumarismita62@gmail.com> wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote: 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> > <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@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 > > 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. 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
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.
On Sun, May 25, 2014 at 5:15 PM, Marc Delisle marc@infomarc.info wrote:
Le 2014-05-25 06:48, Smita a écrit :
On Sat, May 24, 2014 at 11:53 PM, Smita <kumarismita62@gmail.com mailto:kumarismita62@gmail.com> wrote:
On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote: 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> > <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@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 > > hundreds or thousands of column definitions for thisdb.
> > > > 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 namewith
> 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 away 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
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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-
Marc Delisle -
Smita