Gustav:
In any event, I just tested your claim on my host and I was able to
renumber 50,000 records in less than 1/2 second. Even though I
tried it several times, the results were never above 0.47 seconds.
If I was dealing with a database that was accessible to others,
then I would either lock tables or use transaction and then
renumber -- but in either case the difference in time is less than
additional 1/10 of a second.
Ok, it wasn't really a claim, it was more a "feeling", but I
couldn't say it for sure, so I applogize for misleading you there!
:-)
No need to apologize, this is an open discussion -- I'm the one who
is asking questions.
Aha... I missed the part ...
"I was dealing with a database that was accessible to others"
Only YOU are using the db? Ok, then it would not be a problem.
Well both. If I was the only one working with the dB, then there is
no need to lock it down. However, I did set up test where I did lock
it down and another test where I set up a transaction and both added
about a tenth of a second to the alteration of 50,000 records.
Ok, I got your point! :-) But there is another side to it , and that
is scalability. Ok, you don't have so many posts in your database.
Ok, it does take less then a second...
What if you had do make the db visible to other users?
As I said I did a LOCK TABLE, that's where no one can access the
records while I work on them (at least that's my understanding) and
it added about a tenth of a second to the overall time (just over 1/2
second for 50,000 records). I also preformed a transaction
(BEGIN/COMMIT), which my understanding is that it checks to make sure
that the operation can be preformed and then if everything can be
done, then it does it -- an interesting feature.
Then this link that might intrest you: (it's about pitfalls with
transactions as may see in the link)
http://www.onlamp.com/pub/a/php/2003/12/18/transaction_pitfalls.htmlhttp://www.onlamp.com/pub/a/php/2003/12/18/transaction_pitfalls.html
I'll read the link, thanks.
But what If you suddenly hade to change host for some reason... The
new host server maybe wouldn't be as fast as yours is today.
And as someone mentioned, what about if your db was growing to
include a couple of million posts.
Both valid points -- but I know the limits of my customer. If they
post more than 100,000 records in their lifetime, I would be very
surprised.
Of course, if you don't think your db will grow so much, and it
works fine, then of course you could contiuning doing the
ALTER-statement thing, but there's always two sides of the story...
;-)
Well... what I am developing is something for a civilian (i.e., no
programming experience at all). They want to be able to add, edit,
and delete records at their command. I know that I could not explain
why when they deleted a record that they would no longer have the
index again, for I couldn't think of any reason myself -- other than
"it's bad form". So, I needed a way for them to delete a record and
make it easy for them to understand. However, I also wanted to make
sure that I wasn't doing them a disservice -- and thus my questions
to this group -- the other side of the story.
If the ALTER TABLE statement is prone to error, then I would like
to know that and why. However, I suspect that claim isn't true,
it's just that it's misuse has generated an urban myth of "Don't do
that! That's dangerous!" without any real substance other than for
programer error.
*LOL* I have to say, that I agree with you on this one. I've
searched on issues/regarding ALTER TABLE, and could only find errors
regarding this when
Microsoft was involved ;-)
Yeah, I feel sorry for those who rely on M$, but that's another topic.
I have thought of this...
...but isn't there a function in MySQL or PHP to retrieve the
absolute recordnr of a db???
...if there is not, then your code IS good, if you absolutelty need
the functionality! :-)
This exchange has given some ideas. One way is to use a timestamp to
step through the records with a counter that's external to the dB.
That way the customer can see a sequential count, while the dB is
just stepping through records via timestamp. I think I can sell that.
In any event, this exchange has helped me -- so, thanks to all.
tedd
--
--------------------------------------------------------------------------------
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
