<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 25, 2014 at 5:15 PM, Marc Delisle <span dir="ltr"><<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 2014-05-25 06:48, Smita a écrit :<br>
<div class="">><br>
><br>
> On Sat, May 24, 2014 at 11:53 PM, Smita <<a href="mailto:kumarismita62@gmail.com">kumarismita62@gmail.com</a><br>
</div><div class="">> <mailto:<a href="mailto:kumarismita62@gmail.com">kumarismita62@gmail.com</a>>> wrote:<br>
><br>
><br>
><br>
>     On Sat, May 24, 2014 at 10:25 PM, Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a><br>
</div><div class="">>     <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>> wrote:<br>
><br>
>         Le 2014-05-24 12:16, Smita a écrit :<br>
>         ><br>
>         ><br>
>         > On Sat, May 24, 2014 at 9:24 PM, Marc Delisle<br>
>         <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
</div><div><div class="h5">>         > <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>>> wrote:<br>
>         ><br>
>         >     Le 2014-05-24 11:03, Smita a écrit :<br>
>         >     ><br>
>         >     ><br>
>         >     > On Sat, May 24, 2014 at 7:49 PM, Marc Delisle<br>
>         <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
>         >     <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>><br>
>         >     > <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
>         <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>>>> wrote:<br>
>         >     ><br>
>         >     >     Hi Smita,<br>
>         >     >     I have a doubt, looking at the structure you chose<br>
>         for this table:<br>
>         >     >     db_name<br>
>         >     >     column_list<br>
>         >     ><br>
>         >     >     This structure implies that, for any change, you<br>
>         have to load a<br>
>         >     >     potentially big row, decode it and encode it.<br>
>         Imagine that<br>
>         >     there are<br>
>         >     >     hundreds or thousands of column definitions for this db.<br>
>         >     ><br>
>         >     >     I suggest something like:<br>
>         >     ><br>
>         >     >     db_name<br>
>         >     >     column_name<br>
>         >     >     column_attributes<br>
>         >     ><br>
>         >     > Yeah, agree. Thanks, It would be better to keep this. :-).<br>
>         >     > I have a question: If we have "id interger(11) not null<br>
>         >     auto_increment"<br>
>         >     > already existing in central list, should we allow to add<br>
>         another<br>
>         >     column<br>
>         >     > "id integer(20) not null auto_increment" ? If we don't<br>
>         allow then<br>
>         >     we can<br>
>         >     > also keep structure like maybe:<br>
>         >     > db_name<br>
>         >     > column_name<br>
>         >     > column_type<br>
>         >     > column_collation<br>
>         >     > column_isNull<br>
>         >     > column_extra<br>
>         >     ><br>
>         >     > - Smita<br>
>         >     ><br>
>         ><br>
>         >     In a central list, there should be only one column named<br>
>         "id" (but this<br>
>         >     choice of name would be problematic, of course; a better<br>
>         choice would be<br>
>         >     "customer_id").<br>
>         ><br>
>         > So We'll allow only unique column name. If same column name with<br>
>         > different definition tried to add we just show the column name<br>
>         (with<br>
>         > defination) already exist?<br>
><br>
>         Yes; eventually I guess that in your project, there will be a way to<br>
>         directly view the central list and change column definitions.<br>
><br>
>     Yeah, I need to make a page to manage central columns, there users<br>
>     can view complete list of columns and edit some if they want.<br>
><br>
>         ><br>
>         >     Another example is "phone_number"; which is reused in the<br>
>         customer table<br>
>         >     and in the salesperson table. You might want to always use<br>
>         CHAR(25) for<br>
>         >     phone numbers.<br>
>         ><br>
>         >     So it's a good idea to split the attributes into separate<br>
>         columns like<br>
>         >     in your example. The default value could be there too.<br>
>         ><br>
>         > Ok, thanks. We'll keep default as well.<br>
><br>
><br>
> Hi Marc,<br>
> I redesigned the database as discussed.  I completed the adding columns<br>
> part but I got stuck when came to deletion. I have a question.<br>
> Let say I have two tables tbl1 and tbl2, both table has a common column<br>
> name "phone_number". So If user selects both tables and asks to add<br>
> unique columns to central list, then we are gonna add just one<br>
> "phone_number" , let say we add the column/definition "phone_number"<br>
> from tbl1. now let say user select tbl2 and ask to remove columns from<br>
> central list. What should it do ? should it remove the column<br>
> "phone_number" from central list or not ? as "phone_number" was added<br>
> from tbl1.  but "phone_number" exists in tbl2 as well.<br>
><br>
> - Smita<br>
<br>
</div></div>I say we should remove it from the central list. It's up to the user, to<br>
use the feature in a correct way.<br>
<br></blockquote><div>Yeah, agree.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway, say the user added phone_number in tbl3 but never used any<br>
central column option on tbl3. phpMyAdmin won't know that this<br>
phone_number in tbl3 possibly has a different definition, unless there<br>
is an option to manually validate all the tables against the central list.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div> </div><div class="h5">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. <br>
<br></div><div class="h5">
--<br>
Marc Delisle | phpMyAdmin<br>
<br>
------------------------------------------------------------------------------<br>
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE<br>
Instantly run your Selenium tests across 300+ browser/OS combos.<br>
Get unparalleled scalability from the best Selenium testing platform available<br>
Simple to use. Nothing to install. Get started now for free."<br>
<a href="http://p.sf.net/sfu/SauceLabs" target="_blank">http://p.sf.net/sfu/SauceLabs</a><br>
_______________________________________________<br>
Phpmyadmin-devel mailing list<br>
<a href="mailto:Phpmyadmin-devel@lists.sourceforge.net">Phpmyadmin-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel</a><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""></div></blockquote></div><br></div></div>