i remember that last week somebody sent an url to this list explaining why there is a problem with 4.2.1, but i can't find that email in the archive (not knowing what the subject was) ... could somebody please send that url to me?
"Beck, Mike" a écrit :
i remember that last week somebody sent an url to this list explaining why there is a problem with 4.2.1, but i can't find that email in the archive (not knowing what the subject was) ... could somebody please send that url to me?
-- thanks
Mike Beck mikebeck@users.sourceforge.net
Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
See closed bugs 568805 and 559625.
Marc
Hello:
Despite field name changes for the relation table fields in 2.3.0, the relation table field names still seem to be misnamed.
The current names are:
master_db master_table master_field foreign_db foreign_table foreign_field
The primary key for the table is defined as:
PRIMARY KEY (`master_db`,`master_table`,`master_field`)
Unfortunately, this is the reverse of what I think makes sense (and probably the reverse of what most database administrators will understand).
Here's what I mean:
Normally, you have two kinds of keys in a relational database: primary keys and foreign keys. Foreign keys are always primary keys in one--and only one--other table. Consider the following simple example:
Table Products: Product ID << This is a primary key Description
Table Orders: Order ID Product ID << This is a foreign key Quantity
In the current PMA 2.3.0 relation table (if I understand it correctly), we would enter the following values:
master_table: Orders master_field: Product ID foreign_table: Products foreign_field: Product ID
Note that the primary key is called foreign and the the foreign key is called master. Ick.
I suggest reversing the naming of the relation table fields. Also, to make this even more clear, rename 'master' to 'primary', as this DOES refer to the actual primary keys of tables. This would also mean that the primary key for the relation table would be:
PRIMARY KEY (`foreign_db`,`foreign_table`,`foreign_field`)
This makes much more sense. (The same foreign key can be in many tables, but it must always refer to the same primary key.)
Perhaps I am totally misunderstanding, but the PRIMARY KEY definition of the relation table is what set me off, so please correct me if am confused.
Regards,
Jay Davis
Jay Davis wrote:
Hello:
Despite field name changes for the relation table fields in 2.3.0, the relation table field names still seem to be misnamed.
If we take the example "an invoice has many items", it would be clearer to say that the invoice is the *master* table, and items is the *detail* table. A simplified example:
CREATE TABLE invoice ( invoice_id tinyint(4) NOT NULL auto_increment, invoice_date date, PRIMARY KEY (invoice_id))
CREATE TABLE items ( invoice_id tinyint(4), item_number tinyint(4), description varchar(100), PRIMARY KEY (invoice_id, item_number))
---------------------------------------------
If we take the example in Documentation.html:
CREATE TABLE persons ( id tinyint(4) NOT NULL auto_increment, person_name varchar(32) NOT NULL default '', town_code varchar(5) default '0', country_code char(1) NOT NULL default '', PRIMARY KEY (id) ) TYPE=MyISAM;
CREATE TABLE towns ( town_code varchar(5) NOT NULL default '0', description varchar(30) NOT NULL default '', PRIMARY KEY (town_code) ) TYPE=MyISAM;
CREATE TABLE countries ( country_code char(1) NOT NULL default '', description varchar(10) NOT NULL default '', PRIMARY KEY (country_code) ) TYPE=MyISAM;
We can think of the table persons as the master table, because we put the emphasis on the person. Then, the town_code in persons is a foreign key linking to table towns, where town_code is the primary key. But in this case, can we talk about master/detail relationship?
So it's not easy to have only one way to describe various cases, but I think that
the field names in our relation table are clear enough.
Hello:
Dropping an empty table doesn't seem to work in 2.3.0-rc1.
(I've only tried this on one table...)
Regards,
Jay Davis
-
Beck, Mike -
Jay Davis -
Marc Delisle -
Marc Delisle