Re: Delete Only 50 rows from table

Serge Rielau <srielau@ca.ibm.com> wrote in message news:<3aeit3F6a4qi2U1@individual.net>... > Obnoxio The Chav wrote: > > Obnoxio The Chav said: > > > >>Serge Rielau said: > >> > >> > >>>So hwo do you implement queue and to-do style data? > >>>What about an "outstanding orders" table? > >>>A staging table in a warehouse? > >>>Oustanding tickets in a support center? > >> > >>Fuck me gently, Serge, I hope that's a joke? Outstanding orders table? > > > > > > Working on the premise that Germans don't have a sense of humour, and > > Canadian Germans doubly so: > Certainly not yours. > > > > 1. With a status flag. This has the added bonus of being able to re-route > > things or restart a process. If you delete the data, then how can you do > > this? > Isn't that what transactions are there for? > What I see a lot is that multiple processing work of the same queue. > A process marks the "top" row as in process (and commits). Then it does > it's heavy lifting. Finally, the row is deleted. ...and along comes Mr. Customer 6 months later and says "Can I please check the details of order number xyz for my tax returns please?". But you've deleted the row. > Call it what you want but this is what's done out there. Not on my databases it doesn't. > > > 2. You have an orders table. Outstanding orders get a different status flag. > And your order table keeps growing and growing and... > To find the next ordr to process I need to skip all the completes ones.. Indexes. Fragmentation. 'nuff said. > Do you have a todo-list at home? The ever increasing shopping list :-) Bad straw-man analogy. > > > 3. I'm not too sure why a warehouse staging table wouldn't be processed in > > full and then truncated, > > 4. See 1. And 2. > Not if you have a trickle feed. You keep on rolling that stone up the > hill, .... Archiving.