Can you do a "SELECT DISTINCT"
In general, this is a bad thing to do. select distinct is a Red Flag. It may mean that you are making the database engine fetch a far larger result set than necessary. After it has fetched all that, you then tell it to filter the results and discard the duplicates. A much better approach would be to write the query correctly so that the distinct modifier becomes unnecessary.
It may mean that you that you need to consider a column that is not referenced specifically in the record set. The workaround may involve using a subselect, which is not available on databases like MySQL. In that case you are out of luck. Nonetheless, your first reflex should be to try and restructure your query. select distinct should be used only as a last resort.
erm, the "you" doesn't refer to scain here, it refers to you :)
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
A SELECT DISTINCT isn't possible in this case, though it's a good idea and something we'd thought of.
The DB we're using is global, and belongs to a different group to the one I work in. It has data stored how they need it for their reporting, not how we need it for ours - hence the need to concatenate data when duplicates occur on one (of our) orderids.
It's for a fairly specific use, actually: we're trying to have their systems interface with ours for reconciliation purposes, and it's proving to be a lot less simple than I originally thought :)
It'd make a lot more sense if the company had data storage standards, as we're all essentially in different areas of the the same business, but that'd make life easy ... *grin*
-- Foxcub
| [reply] [Watch: Dir/Any] [d/l] |
One more reason to use PostgreSQL.
| [reply] [Watch: Dir/Any] |