mysql-许多表到一个表-多个条目

Question

I have a system which has (for the sake of a simple example) tables consisting of Customers, Vendors, Products, Sales, etc. Total 24 tables at present.

I want to add the ability to have multiple notes for each record in these tables. Eg, Each Customers record could have 0 to many notes, each Vendor record could have 0 to many notes, etc.

My thinking is that I would like to have one "Notes" table, indexed by a Noteid and Date/time stamp. The actual note data would be a varchar(255).

I am looking for a creative way to bi-directionally tie the source tables to the Notes table. The idea of having 24 foreign key type cross reference tables or 24 Notes tables doesn't really grab me.

Programming is being done in PHP with Apache server. Database is mysql/InnoDB.

Open to creative ideas.

Thanks

Ralph

Answer 1

I would sugges a table like this

note_id  :  int autoincrement primary
type_id  :  int, foreign key from f Customers, Vendors, Products etc 
type     :  varchar, code indicating the type, like Vendors, VENDORS or just V 
note     :  varchar, the actual node


CREATE TABLE IF NOT EXISTS `notes` (
  `note_id` int(11) NOT NULL AUTO_INCREMENT,
  `type_id` int(11) NOT NULL,
  `type` varchar(20) CHARACTER SET utf8 NOT NULL,
  `note` varchar(255) CHARACTER SET utf8 NOT NULL,
  PRIMARY KEY (`note_id`)
) 

With a setup like that you can have multiple notes for each type, like Vendors, and also hold notes for multiple types.

data sample

note_id     type_id     type          note
--------------------------------------------------------------------
1           45          Vendors       a note 
2           45          Vendors       another note
3           3           Customers     a note for customer #3
4           67          Products      a note for product #67

SQL sample

select note from notes where type="Vendors" and type_id=45

To reduce table size, I would prefer aliases for the types, like V , P , C and so on.

Answer 2

Don't do a "universal" table, eg

id, source_table, source_record_id, note_text

might sound good in practice, but you can NOT join this table against your others without writing dynamic SQL.

It's far better to simply add a dedicated notes field to every table. This eliminates any need for dynamic sql, and the extra space usage will be minimal if you use varchar/text fields, since those aren't stored in-table anyways.

Answer 3

I've done a structure like this before where I used a format like this:

id (int)
target_type (enum/varchar)
target_id (int)
note (text)

Each data element just has to query for it's own type then, so for your customer object you would query for notes attached to it like this

SELECT * FROM notes where target_type='customer' AND target_id=$this->id

You can also link target_type to the actual class, so that you write to the database using get_class($this) to fill out target type, in which case a single function inside of the Note class could take in any other object type you have.

Answer 4

In my opinion, there isn't a clean solution for this.

option 1: Master entity table

Every (relevant) row of every (relevant) table has a master entry inside a table (let's call it entities_tbl . The ids of each derived table isn't an autoincrement but it's a foreign key referencing the master table.

Now you can easily link the notes table with the master entity id.

PRO: It's an object oriented idea. Like a base "Object" class which is the father of every other class. Also, each entity has an unique id across the database.

CON: It's a mess. Every entity ID is scattered among (at least) two tables. You'd need JOINs every single time, and the master entity table will be HUGE (it will contain the same number of rows as the sum of every other child table, combined)

option 2: meta-attributes

inside the notes table, the primary key would contain an autoincrement, the entity_id and item_table_name. This way you can easily extract the notes of any entity from any table.

PRO: Easy to write, easy to populate CON: It needs meta-values to extract real values. No foreign keys to grant referential integrity, messy and sloppy joins, table names as where conditions.

option 3: database denormalization

(sigh, I've never considered to ever give this suggestion) Add a column inside each table where you need notes. Store the notes as json encoded strings. (this means to denormalize a database because you will introduce non-atomic values)

PRO: easy and fast to write, uses some form of standard even for future database users, the notes are centralized and easily accessible from each entity CON: the database isn't normalized, poor search and comparison between notes