Thanks for all .. I really appreciate your effort .. now I have a solid idea of how I should do Thanks a lot On Sun, Nov 27, 2011 at 10:28 PM, Larry Garfield <larry@xxxxxxxxxxxxxxxx>wrote: > On 11/26/2011 09:45 PM, Paul M Foster wrote: > >> On Sat, Nov 26, 2011 at 01:26:49PM -0600, Tamara Temple wrote: >> >> muad shibani<muad.shibani@xxxxxxxxx**> wrote: >>> >>> i wanna to create one table that contains both news and articles posts, >>>> they have similar columns like id, title, content, and date but they are >>>> differ in one column = the source of news or article post >>>> article has writers that have permanent names and pictures obtained >>>> from >>>> another table called writers that supposed to be left joined with the >>>> news >>>> table, while news posts simply have a source as text like AFP >>>> or Reuters and so one. >>>> >>>> How I can solve this ? >>>> >>> >>> How you store things in tables can sometimes get a little tricky. One >>> way to approach this is with normalized tables and using joins in your >>> query like you are doing. To make this work, in your main entries table, >>> have a field that indicates what the entry type is. If you are doing one >>> select that gets both articles and news stories, having that extra field >>> can help you distinguish what type it is, and which fields contain data >>> in each record. >>> >>> (cf: Wordpress wp_posts table for an example of how this is done. They >>> store posts, pages, and attachments in a single table this way. I can't >>> say if this is a better arrangement than keeping them in separate >>> tables.) >>> >> >> I've had to hack this table. It's a prime example of bad design. Take a >> long look at the records of this table in an active blog, with a survey >> of each of the fields and their values. You'll see what I mean. >> >> Paul >> > > The Drupal approach to this problem is to have a common table for all > "nodes" (our generic content object thingie), and then dependent tables for > type-specific stuff. So (over-simplifying): > > node: id, title, type, created time, updated time, published (1 or 0) > field_body: node_id, delta, value > field_picture: node_id, delta, url > field_source: node_id, delta, url to reuters or whatever > field_writers: node_id, delta, writer name, url to writer picture > // etc. > > That way, you can have the basic information all in one table and then > specific fields can be shared by some, all, or just one node type, and all > can be multi-value. It does mean loading up a full object is multiple > queries, but really, MySQL is fast. You don't need to over-optimize your > query count, and this gets you a well-normalized database. > > If you know in advance exactly what your types are going to be (in Drupal > they're user-configurable), you could simplify it to something like: > > node: id, title, type, body. created time, updated time, published (1 or 0) > node_article: node_id, writer name, writer picture url > node_news: node_id, url to reuters or whatever > > And you can still select on whatever you need. With a LEFT JOIN, you can > even get back all data on all articles of both types, and just have lost of > nulls in the result set for the off-record fields. > > --Larry Garfield > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- *_______________* * * السجل .. كل الأخبار من كل مكان www.alsjl.com صفحة السجل على فيسبوك http://www.facebook.com/alsjl *Muad Shibani* * * Aden Yemen Mobile: 00967 733045678 www.muadshibani.com
