Re^2: Testing if an array contains a value and then deleting it in most efficient way

In fact the values to be looked-up will come numerically sorted (probably if the record IDs in db are really ordered by their numeric ID), so sorting the values in the array would mean that only first element is deleted.
So it seems that I can only ask whether the value to be looked up equals just the first item of the array! How only could miss it? Tx for pointing the possibility of ordering.
Undefs are ignored during the search, so their presence doesnt slowdown the procedure?

Comment on Re^2: Testing if an array contains a value and then deleting it in most efficient way

Replies are listed 'Best First'.
Re^3: Testing if an array contains a value and then deleting it in most efficient way by ikegami (Patriarch) on Feb 18, 2008 at 16:37 UTC
Fortunately for you, deleting the first (or last) element of an array (`shift(@a)`) is very fast (O(1)) in Perl.	[reply] [d/l]
Re^4: Testing if an array contains a value and then deleting it in most efficient way by karpatov (Beadle) on Feb 18, 2008 at 16:45 UTC
There is one problem though, the values to be check against the array come from a db which is splitted into several files, so their names something0001,something1000 should be ordered but @files = sort { $a <=> $b } @files causes the IDE to freeze. What can be wrong? tx.	[reply]
Re^3: Testing if an array contains a value and then deleting it in most efficient way by parv (Parson) on Feb 18, 2008 at 16:43 UTC
A side note ... The records may be sorted but will not be returned as such when not asked, if database server is Sybase 15.0.x.	[reply]
Re^4: Testing if an array contains a value and then deleting it in most efficient way by mpeppler (Vicar) on Feb 19, 2008 at 11:03 UTC
Even more of a side note - one should never rely on the inherent ordering of data in a SQL database. Any ordering is a side effect of the storage mechanism, and can change (for example due to parallel query engines). Always use an ORDER BY clause if the order of the returned data is significant in any way! Michael PS - for Sybase it's not only ASE 15.0.x that has this behavior - it's any table that has row-level locking (DOL), or if you have partitioned tables, or if you use parallel queries.	[reply]
OT: Sybase by parv (Parson) on Feb 19, 2008 at 11:24 UTC
Currently being trained on the job as a DBA (to a level enough to keep servers working), I appreciate your post script much. In any case, change from all-page lock to any other locking scheme won't come as shocking surprise now (w.r.t. output ordering) after switching from 12.0 to 15.0.x.	[reply]


Keep It Simple, Stupid
	PerlMonks