That seems unreasonably harsh.
I can see what you mean, but don't take it that way. I was trying to
help.
What in your view is wrong with a union query that preserves an
indicator of which component table a particular record comes from?
Read earlier in the thread. He's talking about adding a field to the
table and that the value of this field in every single record will be
the name of the table the record belongs to. I said I would
definitely not recommend doing that.
I can easily imagine a circumstance in which this could be
valuable, say the union of several mailing lists that are in
separate tables simply because they originate from different
sources. We union them to print a single alphabetical list, for
example, but we want an indicator as to the source of each record.
I can imagine modifying the OP's query to read:
$sql=" (select '1' as tableId, * from table_1 WHERE pid='0' order
by id desc limit 10) union
(select '2' as tableId, * from table_2 WHERE pid='0' order
by id desc limit 10) union
(select '3' as tableId, * from table_3 WHERE pid='0' order
by id desc limit 10) union
(select '4' as tableId, * from table_4 WHERE pid='0' order
by id desc limit 10)
order by date desc limit 10 ";
Would this be so egregious? and if so why?
I think this is a great solution, wish I'd thought of it. =)
You say,
If you need to combine data from more than one table,
code your application to respond accordingly.
What does this mean, exactly?
I'm just talking about intelligent programming.
Surely you're not suggesting that we code an application to somehow
divine the source of a record in a union query when the query
itself could simply supply that datum easily.
Of course not. Honestly, I think you're just being critical of what
I said, because you thought I was being harsh and unfair when I
wasn't actually trying to be.
-Ed
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
