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 <>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<**>  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 (
> To unsubscribe, visit:

السجل .. كل الأخبار من كل مكان

صفحة السجل على فيسبوك

*Muad Shibani*
Aden Yemen
Mobile: 00967 733045678

Reply via email to