On Tue, Mar 30, 2010 at 8:38 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Mar 30, 2010 at 08:07:01PM -0700, Tommy Pham wrote: > >> On Tue, Mar 30, 2010 at 7:37 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> >> wrote: >> > >> > Unless you have some compelling need to store a number like this, I >> > don't see the need to. What I store is what is called in PostgreSQL a >> > "serial" value. MySQL calls it "auto_increment". You store all the other >> > values as a row, and the DBMS adds in the "auto_increment"/"serial" >> > value for you. It's an integer, *usually* one larger than the last value >> > entered. >> > >> > Paul >> > >> >> The (personal) project I'm about to start will run in several threads >> (thinking how can I make this happen in PHP) where the inserts could >> be multiple inserts at once. Identity (type) insert doesn't behave >> nicely (locking up the DB) when there are multiple inserts at once. >> Using UUID is one of the possible solution to resolving this problem >> for me. > > I initially misunderstood your request. > > But what DBMS are you using that locks up on multiple simultaneous > inserts? Any reasonable DBMS (besides SQLite) ought to queue inserts and > execute them without locking up. > In the past, I've not implement anything close to what I'm about to do. Initial test run of the app will be about 10 threads. Live run expected to be excess of 100 threads (and DB connections). Thus, I've yet to encounter the locking problems, but I've read many DB articles, in the past few years, from different sources. Some of those state that lockup will happen when multiple simultaneous inserts occur. > I think I still don't understand what you're trying to do. It appears > you're trying to get around an insert-locking problem by using UUIDs. > But I'm not sure how a UUID will resolve your problem. As far as the > DBMS is concerned, and insert is an insert, regardless of what you're > storing. A UUID would just be another field to store; it could be any > datatype, as far as the DBMS is concerned. Now, if you actually mean > *updates*, that may be a different matter. But again, the DBMS should > queue them. > > I will say this-- if you're looking to add a unique identifier to each > record (I presume the reason for the UUID), and you're going to need > more than 2 billion records (32-bit platform), or 9 quadrillion records > (64-bit platform), integers or serials won't do. In PostgreSQL, you can > specify arbitrary precision numbers up to 1000 digits of precision as: > > uuid number(128) > > which would be what you're looking for. But you'd have to generate that > value yourself, as only a PostgreSQL "serial" type (integer) will > automatically increment. > > Hope that helps (but I doubt it). > > Paul > PostgreSQL have several functions to generate it: http://www.postgresql.org/docs/8.3/static/uuid-ossp.html MySQL has UUID(). MSSQL has NEWID(). Don't remember top of my head what Oracle has. Don't know about Firebird as I have zero experience with it. The adequate # of rows (of URL) I need is at least 1 billion. Given that if I fetch 1 URL / sec, it would take me at least 31 years :)). If I can get it to run smoothly with over 100 threads, I'd have that data in less 1/3 year :D -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
