Re: Product ID - enterprise level application

One note I don't use the uuid as the primary key in these instances. I know that's how this post started. :) -- Ryan LeTulle On Fri, Jun 12, 2009 at 9:07 AM, Mary Jo Sminkey wrote: > > >Are you guys saying that I should force my client to require their client > to > >create a user account?

Re: Product ID - enterprise level application

>Are you guys saying that I should force my client to require their client to >create a user account? Or am I missing something here in the symantics. > Because I don't see another solution. If they want to view order history, yes, that's the easiest way to ensure security for viewing the info

RE: Product ID - enterprise level application

that are dependent on existing values that is) .:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com http://cf4em.com -Original Message- From: Peter Boughton [mailto:bought...@gmail.com] Sent: Friday, June 12, 2009 8:13 AM To: cf-talk Subject: Re: Product ID - enterprise level applic

Re: Product ID - enterprise level application

Thank you all. A long habit of not thinking a thing wrong gives it a superficial appearance of being right. Thomas Paine * *-- Ryan LeTulle On Fri, Jun 12, 2009 at 7:12 AM, Peter Boughton wrote: > > >Are you saying that a uuid

Re: Product ID - enterprise level application

>Are you saying that a uuid is inherently insecure? UUIDs are guaranteed to be unique, but not (afaik) to be unpredictable. I don't know *how* predictable they might be, but for any secure string I wouldn't want to rely entirely on something with potentially knowable/guessable sources - I woul

Re: Product ID - enterprise level application

OK, I guess. :) -- Ryan LeTulle On Fri, Jun 12, 2009 at 7:01 AM, Jochem van Dieten wrote: > > On Fri, Jun 12, 2009 at 1:38 PM, Ryan Letulle wrote: > > Are you saying that a uuid is inherently insecure? > > Depends on how you use them. > > > > I thought part of the > > uuid was created randomly

Re: Product ID - enterprise level application

On Fri, Jun 12, 2009 at 1:38 PM, Ryan Letulle wrote: > Are you saying that a uuid is inherently insecure? Depends on how you use them. > I thought part of the > uuid was created randomly and for the purposes where I was using it felt > comfortable. Some UUIDs are random, some are completely pr

Re: Product ID - enterprise level application

> > Doesn't require a UUID as the PK, just something unique and unpredictable > for that piece of functionality, which could be derived/hashed from any > static column(s). Peter, Are you saying that a uuid is inherently insecure? I thought part of the uuid was created randomly and for the purpo

Re: Product ID - enterprise level application

Are you guys saying that I should force my client to require their client to create a user account? Or am I missing something here in the symantics. Because I don't see another solution. BTW I am not talking about guarding Fort Knox here. -- Ryan LeTulle On Fri, Jun 12, 2009 at 4:21 AM, Tom

Re: Product ID - enterprise level application

On Friday 12 Jun 2009, Ryan Letulle wrote: > An example would be for an emailed order confirmation with a link back to > their order details. ... By using an > integer it would be extremely easy for someone to view other order details > but not so with a uuid. But surely your getOrderFromOrderId(

Re: Product ID - enterprise level application

On Fri, Jun 12, 2009 at 9:59 AM, Dave Watts wrote: >> An example would be for an emailed order confirmation with a link back to >> their order details.(in this case the client does not want someone to fill >> out user details and create an account for their own reasons)  By using an >> integer it

Re: Product ID - enterprise level application

>(in this case the client does not want someone to fill >out user details and create an account for their own reasons) By using an >integer it would be extremely easy for someone to view other order details Doesn't require a UUID as the PK, just something unique and unpredictable for that piece

Re: Product ID - enterprise level application

> Nothing to do with security measures for me.  Many times I simply don't want > anyone accessing another record in the database.  I am sure that you can > imagine that type of scenario, in case not > An example would be for an emailed order confirmation with a link back to > their order detai

Re: Product ID - enterprise level application

Nothing to do with security measures for me. Many times I simply don't want anyone accessing another record in the database. I am sure that you can imagine that type of scenario, in case not An example would be for an emailed order confirmation with a link back to their order details.(in thi

Re: Product ID - enterprise level application

>The tradeoff will be between a user not being able to play around with the >querystring (i.e change id=1 to id=2) Huh!? Please tell me you don't use UUIDs as an alternative to having proper security/permissions in place? Because if you do have proper security there is no playing around that c

Re: Product ID - enterprise level application

Eventually integers do get too large for the database field. If you're truly adding a million new IDs / day, that could happen. There's a fairly modest upper limit to 'int', so definitely look at 'bigint' (SQL Server) to handle integer IDs if you take that route. ~

Re: Product ID - enterprise level application

The tradeoff will be between a user not being able to play around with the querystring (i.e change id=1 to id=2) and performance. How much performance I can't say. A million a day I would think you would start to see it. I personally haven't hit the performance issue with uuid but I also haven't

Product ID - enterprise level application

I am wondering the best way to create an ID for an online advertising site that I anticipate could have about a million products uploaded a day. I had considered using create UUID I read the following from Christian Cantrell "If you want the convenience of generating your own primary key witho