RE: TR: UUID's ( maybe OT)
Parameters for a static file? Or does vignette use .html as an extension for an ISAPI filter? Yes, it could be any extension. So the 1674 part is the only part of all that which is actually useful eh? :) No, all the parameters are usefull (0,1674,P249,00), especially P249 and 00. I re-explain : 1674 is the ID of the template to execute, P249 is the OID to pass to the template (it could be a list of parameters) and 00 are the capabilities of the browser. If the template display an article, it will generate one static html file per article (one per OID) for each browser capabilities (if there is any difference for each browser in the output). Ex. : - 0,1674,P249,00.html, - 0,1674,P249,FF.html, - 0,1674,P250,00.html, - 0,1674,P251,00.html... If the 0,1674,P249,00.html file already exists in the cache directory, it is directly served by the web server without any dynamic processing. If you can also use URL parameters (0,1674,P249,00.html?var1=totovar2=titi), but if the template is cached, they won't be taken into account (ignored by the web server), that's why you can't put P249 as a normal URL parameter, it has to be in the file name for the caching system to work. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? We've designed, developped and run several high-end B2C web sites and we never had to encounter this kind of problem. All our applications have automatic error trapping system and nicely structured navigation system. They also have friendly URLs. ;) In my previous mail, I was not saying, that Vignette naming was a great one. I was just explaining that it was linked to the way their caching system works. I definitely agree : if you can have friendly URL, you should keep them friendly (and avoiding UUID is already one way to do it). Why making thing complex, if you can make them simple is a CF motto... ;) Benoit Hediard -Message d'origine- De : S. Isaac Dealey [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 19 septembre 2002 23:27 À : CF-Talk Objet : Re: TR: UUID's ( maybe OT) I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/Page Generator/0,1674,P 249,00.html Just for your information, Vignette use 0,1674,P249,00.html URL format for caching purpose. The name of the file contains all the parameters used to generate content for a given template : 0 means that cache can be used (dynamic generation is not forced), 1674 is the template ID, P249 is the parameter (could be a parameters list) Parameters for a static file? Or does vignette use .html as an extension for an ISAPI filter? , 00 describes browser capabilities. So the 1674 part is the only part of all that which is actually useful eh? :) It allow Vignette to automatically generate physical cache files that can later be serve directly by the web server. Once the cache has been generated, the dynamic web site behave like a static web site, the web server only serves static html pages. Yes, Tapestry does this... or it can if you need/want it to -- it's not a necessity. But it is a native feature of the application. This is a pretty clever caching system which made the success of Vignette .. 5 years ago (and this is how Vignette handles tremendous loads). If you say so, but I'm fairly certain Vignette doesn't do anything with that url than I can't do with a 4 or 5 digit number. As a matter of fact, I'd be willing to bet that much of this is already done by Tapestry -- the caching that is... So OK, the URL aren't very URL friendly, but I don't think that URL have to be friendly. User never look at the URLs, only web developers do.. ;) Did you get a chance to read my first message on this thread? Real non-developer people frequently look at those url's, and often have to give them to people over the phone, which is a major pain... Sounds like you've never worked in a tech-support queue -- as just one example of an instance in which non-developer people must frequently pass a url verbally. I worked in Hewlett Packard's corporate tech-support queue for a year ( was actually my first technical job ), and the fact that their corporate website where people had to get drivers was a nightmare to navigate was a _huge_ problem. They didn't use Vignette, but something like what you see below was a _common_ occurrance on the phone. And this was even talking mostly to IT and MIS department techs whos job it was to repair our workstations. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty
RE: TR: UUID's ( maybe OT)
In my previous mail, I was not saying, that Vignette naming was a great one. I was just explaining that it was linked to the way their caching system works. I definitely agree : if you can have friendly URL, you should keep them friendly (and avoiding UUID is already one way to do it). Why making thing complex, if you can make them simple is a CF motto... ;) Yea, I think I was misinterpreting your response... I've been pretty keyed-up lately actually... I'm doing outside consulting work and the best I've been able to get recently has been an MLM scheme which I really dislike .. but it's a paycheck. Vignette's caching system still doesn't sound all that dissimilar from Tapestry's accept that Tapestry doesn't generate the cached templates in response to visitor requests -- it generates them on a schedule or in response to a manual update by a Tapestry user with permission to view the Update Manager. And browser capabilities isn't a native feature of Tapestry although there's nothing preventing browser identification and tailoring being added in any number of ways, either by adding features to the core application or by managing the customizable, object-oriented content types. Isaac Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: UUID's ( maybe OT)
Bryan Love wrote: Not really true. The word terrible is a vast overstatement. Assuming you use char (or varchar) for the UUID (char is better since the size is constant)... The difference btwn string keys and numeric keys (performance-wise) is pretty much null until you get up into the millions of records and even then it's not enough to worry about. ok some simple maths, a uuid is what 30 chars or something, that means a join using two tables with lets say 1 and 3000 rows.. that means a query between the two is going to be working with either 13000 bytes or 13000 * 30 bytes just to join data... the answer there is that you are working with 30 times the amount of data, sure there is some optimzation but the logic goes further.. each index requires space, both memory and disk space... db's usually try and cache the indexes in ram sure the db can probably do some magic here and the difference is not 30 times in processing speed..but you will still need 30x more cache for your indexes but then each of pages will then contain x * content links * 30 more data, which means more transfer between your db and webserver, more bandwidth costs as all your pages are then bigger... z __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
TR: UUID's ( maybe OT)
I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/PageGenerator/0,1674,P 249,00.html Just for your information, Vignette use 0,1674,P249,00.html URL format for caching purpose. The name of the file contains all the parameters used to generate content for a given template : 0 means that cache can be used (dynamic generation is not forced), 1674 is the template ID, P249 is the parameter (could be a parameters list), 00 describes browser capabilities. It allow Vignette to automatically generate physical cache files that can later be serve directly by the web server. Once the cache has been generated, the dynamic web site behave like a static web site, the web server only serves static html pages. This is a pretty clever caching system which made the success of Vignette .. 5 years ago (and this is how Vignette handles tremendous loads). So OK, the URL aren't very URL friendly, but I don't think that URL have to be friendly. User never look at the URLs, only web developers do.. ;) As for UUID, they are only required as Shlomy Gantz said for synchronization and aggregation of content and data from globally distributes sub-systems : where different applications have to create PK for the same content (that is what UUID has been designed for). Otherwise, UUID are just plain overhead. Benoit Hediard http://www.benorama.com -Message d'origine- De : S. Isaac Dealey [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 18 septembre 2002 22:13 À : CF-Talk Objet : RE: UUID's ( maybe OT) I don't really know much about most other vendors' cms, but this is one of the things I dislike about a number of cms that I've seen (from the outside anyway) ... I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/PageGenerator/0,1674,P 249,00.html ( this is the signiature url-format of Vignette's StoryServer ) when a url like http://www.metlife.com/50598.html should suffice for just about anything, regardless of how much content you have. I could have fifty thousand pages in that site, or I could have fifty-BILLION pages in that site and it wouldn't matter, I could still use a reasonably simple url like this. I can't imagine those long content entry id's in StoryServer and the like help the software do its job quickly or efficiently either... And the really nice thing about using numbers is, not only are they short, but the length of the string only increases at 1/10th the rate of content increase, so the numbers stay small and easy for people to remember or write down or repeat to someone over the phone. As opposed to the 2 minute ordeal I would go through copying down a url like above on paper and double-checking to be sure it's correct. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty hearing or understanding it: http://www.metlife.com/applications/corporate/wps ... . w - p as in paul - s as in sam ... slash . c as in cat, d as in dog, a as in apple... PageGenerator ... p as in paul, a as in apple, g as in golf, e as in echo... Ten minutes later they have the url and your average call-time's gone through the roof. God forbid the person is hard of hearing or just plain computer illiterate. /rant Not that there isn't any place for UUID's ... A place they'd be useful? How about a system where incident or report tickets are input into a central repository but are being generated from multiple individual locations? ... sure... Generate a UUID at the location where the report or incident is created, along with a local numeric identity key. When you import the data from your multiple locations, you take in a location id, a local unique number, and a UUID -- someone searching the central repository can pick out an individual entry by entering a combination of a location id and local unique identifying number, or a UUID, or a unique number generated at the central repository. The UUID is the official or cardinal identifier, so if you're not able to retreive data from any of the other identifiers, the UUID is what you fall back on as the authoritative answer / identifier. So when someone at location a calls and says I need info on ticket #50 for location a, and you can't find the ticket, you ask them for the UUID and if the UUID doesn't exist, then they're just SOL. :) If it does exist, then you can determine if it's mislabelled ( the import mangled the location id or the local identifier ) and fix that problem. S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has
Re: UUID's ( maybe OT)
Zac Spitzer wrote: Bryan Love wrote: Not really true. The word terrible is a vast overstatement. Assuming you use char (or varchar) for the UUID (char is better since the size is constant)... The difference btwn string keys and numeric keys (performance-wise) is pretty much null until you get up into the millions of records and even then it's not enough to worry about. ok some simple maths, a uuid is what 30 chars or something, that means a join using two tables with lets say 1 and 3000 rows.. that means a query between the two is going to be working with either 13000 bytes or 13000 * 30 bytes just to join data... the answer there is that you are working with 30 times the amount of data, sure there is some optimzation but the logic goes further.. Because primary keys are always indexed, and the fields in your db used for joins should also be, it would be a join on idexes, these are usually faster then unindexed numeric joins. Indexed numeric joins are just as fast (also joining on indexes). Jesse __ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: TR: UUID's ( maybe OT)
I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/Page Generator/0,1674,P 249,00.html Just for your information, Vignette use 0,1674,P249,00.html URL format for caching purpose. The name of the file contains all the parameters used to generate content for a given template : 0 means that cache can be used (dynamic generation is not forced), 1674 is the template ID, P249 is the parameter (could be a parameters list) Parameters for a static file? Or does vignette use .html as an extension for an ISAPI filter? , 00 describes browser capabilities. So the 1674 part is the only part of all that which is actually useful eh? :) It allow Vignette to automatically generate physical cache files that can later be serve directly by the web server. Once the cache has been generated, the dynamic web site behave like a static web site, the web server only serves static html pages. Yes, Tapestry does this... or it can if you need/want it to -- it's not a necessity. But it is a native feature of the application. This is a pretty clever caching system which made the success of Vignette .. 5 years ago (and this is how Vignette handles tremendous loads). If you say so, but I'm fairly certain Vignette doesn't do anything with that url than I can't do with a 4 or 5 digit number. As a matter of fact, I'd be willing to bet that much of this is already done by Tapestry -- the caching that is... So OK, the URL aren't very URL friendly, but I don't think that URL have to be friendly. User never look at the URLs, only web developers do.. ;) Did you get a chance to read my first message on this thread? Real non-developer people frequently look at those url's, and often have to give them to people over the phone, which is a major pain... Sounds like you've never worked in a tech-support queue -- as just one example of an instance in which non-developer people must frequently pass a url verbally. I worked in Hewlett Packard's corporate tech-support queue for a year ( was actually my first technical job ), and the fact that their corporate website where people had to get drivers was a nightmare to navigate was a _huge_ problem. They didn't use Vignette, but something like what you see below was a _common_ occurrance on the phone. And this was even talking mostly to IT and MIS department techs whos job it was to repair our workstations. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty hearing or understanding it: http://www.metlife.com/applications/corporate/wps ... . w - p as in paul - s as in sam ... slash . c as in cat, d as in dog, a as in apple... PageGenerator ... p as in paul, a as in apple, g as in golf, e as in echo... Ten minutes later they have the url and your average call-time's gone through the roof. God forbid the person is hard of hearing or just plain computer illiterate. Generally speaking I think it's foolish to assume that non-technical people will never do or need to do something when it regards your software -- especially when it's something as necessary and readily available as a URL. Users will do what they need to in order to accomplish anything that's really important ( in the case of the tech-support person, it's their job to make sure that people can get the drivers they need, etc. ) but we don't need to go out of our way to make things complicated for them. Isaac Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 __ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
UUID's ( maybe OT)
I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? ..tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Zac Spitzer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:16 PM To: CF-Talk Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: UUID's ( maybe OT)
It depends what you want to do. In some cases, UUIDs are better for security purposes. The web surfer cannot easily guess the next in the line or simply change a URL variable to see something they shouldn't. ( And for the record, There was a way to avoid this Lotus Notes long complicated too long for the browser to handle ) At 07:15 PM 9/18/2002 +0200, you wrote: I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: UUID's ( maybe OT)
UUIDs with a datatype of uniquidentifier are indexed just as pk's - Original Message - From: Zac Spitzer [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:15 AM Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
I don't really know much about most other vendors' cms, but this is one of the things I dislike about a number of cms that I've seen (from the outside anyway) ... I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/PageGenerator/0,1674,P 249,00.html ( this is the signiature url-format of Vignette's StoryServer ) when a url like http://www.metlife.com/50598.html should suffice for just about anything, regardless of how much content you have. I could have fifty thousand pages in that site, or I could have fifty-BILLION pages in that site and it wouldn't matter, I could still use a reasonably simple url like this. I can't imagine those long content entry id's in StoryServer and the like help the software do its job quickly or efficiently either... And the really nice thing about using numbers is, not only are they short, but the length of the string only increases at 1/10th the rate of content increase, so the numbers stay small and easy for people to remember or write down or repeat to someone over the phone. As opposed to the 2 minute ordeal I would go through copying down a url like above on paper and double-checking to be sure it's correct. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty hearing or understanding it: http://www.metlife.com/applications/corporate/wps ... .. w - p as in paul - s as in sam ... slash .. c as in cat, d as in dog, a as in apple... PageGenerator ... p as in paul, a as in apple, g as in golf, e as in echo... Ten minutes later they have the url and your average call-time's gone through the roof. God forbid the person is hard of hearing or just plain computer illiterate. /rant Not that there isn't any place for UUID's ... A place they'd be useful? How about a system where incident or report tickets are input into a central repository but are being generated from multiple individual locations? ... sure... Generate a UUID at the location where the report or incident is created, along with a local numeric identity key. When you import the data from your multiple locations, you take in a location id, a local unique number, and a UUID -- someone searching the central repository can pick out an individual entry by entering a combination of a location id and local unique identifying number, or a UUID, or a unique number generated at the central repository. The UUID is the official or cardinal identifier, so if you're not able to retreive data from any of the other identifiers, the UUID is what you fall back on as the authoritative answer / identifier. So when someone at location a calls and says I need info on ticket #50 for location a, and you can't find the ticket, you ask them for the UUID and if the UUID doesn't exist, then they're just SOL. :) If it does exist, then you can determine if it's mislabelled ( the import mangled the location id or the local identifier ) and fix that problem. S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? ..tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Zac Spitzer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:16 PM To: CF-Talk Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
My DBE tells me, however, that UUIDs (or GUIDs) are terrible for joins. Better to just use integers. -Original Message- From: Brian Thornton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 3:59 PM To: CF-Talk Subject: Re: UUID's ( maybe OT) UUIDs with a datatype of uniquidentifier are indexed just as pk's - Original Message - From: Zac Spitzer [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:15 AM Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? Well, ntext is a datatype in SQL Server, but I don't think you'd want to use it for your primary key fields. You might not have much overhead using UUID fields for joins compared to integers, but I'm sure there's some. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 : dream :: design :: develop : MXDC 02 :: Join us at this all day conference for designers developers to learn tips, tricks, best practices and more for the entire Macromedia MX suite. September 28, 2002 :: http://www.mxdc02.com/ (Register today, seats are limited!) :: __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: UUID's ( maybe OT)
The url would be indexed :) - Original Message - From: S. Isaac Dealey [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 1:12 PM Subject: RE: UUID's ( maybe OT) I don't really know much about most other vendors' cms, but this is one of the things I dislike about a number of cms that I've seen (from the outside anyway) ... I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/PageGenerator/0,1674,P 249,00.html ( this is the signiature url-format of Vignette's StoryServer ) when a url like http://www.metlife.com/50598.html should suffice for just about anything, regardless of how much content you have. I could have fifty thousand pages in that site, or I could have fifty-BILLION pages in that site and it wouldn't matter, I could still use a reasonably simple url like this. I can't imagine those long content entry id's in StoryServer and the like help the software do its job quickly or efficiently either... And the really nice thing about using numbers is, not only are they short, but the length of the string only increases at 1/10th the rate of content increase, so the numbers stay small and easy for people to remember or write down or repeat to someone over the phone. As opposed to the 2 minute ordeal I would go through copying down a url like above on paper and double-checking to be sure it's correct. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty hearing or understanding it: http://www.metlife.com/applications/corporate/wps ... .. w - p as in paul - s as in sam ... slash .. c as in cat, d as in dog, a as in apple... PageGenerator ... p as in paul, a as in apple, g as in golf, e as in echo... Ten minutes later they have the url and your average call-time's gone through the roof. God forbid the person is hard of hearing or just plain computer illiterate. /rant Not that there isn't any place for UUID's ... A place they'd be useful? How about a system where incident or report tickets are input into a central repository but are being generated from multiple individual locations? ... sure... Generate a UUID at the location where the report or incident is created, along with a local numeric identity key. When you import the data from your multiple locations, you take in a location id, a local unique number, and a UUID -- someone searching the central repository can pick out an individual entry by entering a combination of a location id and local unique identifying number, or a UUID, or a unique number generated at the central repository. The UUID is the official or cardinal identifier, so if you're not able to retreive data from any of the other identifiers, the UUID is what you fall back on as the authoritative answer / identifier. So when someone at location a calls and says I need info on ticket #50 for location a, and you can't find the ticket, you ask them for the UUID and if the UUID doesn't exist, then they're just SOL. :) If it does exist, then you can determine if it's mislabelled ( the import mangled the location id or the local identifier ) and fix that problem. S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? ..tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Zac Spitzer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:16 PM To: CF-Talk Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http
RE: UUID's ( maybe OT)
http://www.codebits.com/uuid/index.htm a great explanation about why you should use UUID (by David Medinets). Personally I use UUIDs for large applications since it solves a lot of problems in synchronization and aggregation of content and data from globally distributes sub-systems. However, in many cases UUID are just plain overkill. I use UUIDs in Oracle more than in MSSQL simply because the affect on performance is very minimal in Oracle. my 2c Shlomy -Original Message- From: Everett, Al [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:33 PM To: CF-Talk Subject: RE: UUID's ( maybe OT) My DBE tells me, however, that UUIDs (or GUIDs) are terrible for joins. Better to just use integers. -Original Message- From: Brian Thornton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 3:59 PM To: CF-Talk Subject: Re: UUID's ( maybe OT) UUIDs with a datatype of uniquidentifier are indexed just as pk's - Original Message - From: Zac Spitzer [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:15 AM Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
well gee i wouldnt use a text (datatype) column for one either but that wasnt the point of my question. the point was, in making some sort of datatype like that, where it follows a format as far as its makeup and probably is derived through some sort of algorithm, you would think that there would be some built in functionality that made it a bit faster than a varchar with the same string of data in it. tw -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 5:18 PM To: CF-Talk Subject: RE: UUID's ( maybe OT) but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? Well, ntext is a datatype in SQL Server, but I don't think you'd want to use it for your primary key fields. You might not have much overhead using UUID fields for joins compared to integers, but I'm sure there's some. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 : dream :: design :: develop : MXDC 02 :: Join us at this all day conference for designers developers to learn tips, tricks, best practices and more for the entire Macromedia MX suite. September 28, 2002 :: http://www.mxdc02.com/ (Register today, seats are limited!) :: __ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: UUID's ( maybe OT)
Not really true. The word terrible is a vast overstatement. Assuming you use char (or varchar) for the UUID (char is better since the size is constant)... The difference btwn string keys and numeric keys (performance-wise) is pretty much null until you get up into the millions of records and even then it's not enough to worry about. Also, I saw a comment about nText. nText stores information in unicode so each character in a string has an accompanying unicode key. This doubles the storage size of strings and I believe it slows processing (although I'm not sure on that one) so it's not generally a good idea. If you're gonna use nText, nChar, nVarchar, make sure you have a really good reason! +---+ Bryan Love Macromedia Certified Professional Internet Application Developer Database Analyst TeleCommunication Systems [EMAIL PROTECTED] +---+ ...'If there must be trouble, let it be in my day, that my child may have peace'... - Thomas Paine, The American Crisis Let's Roll - Todd Beamer, Flight 93 -Original Message- From: Everett, Al [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:33 PM To: CF-Talk Subject: RE: UUID's ( maybe OT) My DBE tells me, however, that UUIDs (or GUIDs) are terrible for joins. Better to just use integers. -Original Message- From: Brian Thornton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 3:59 PM To: CF-Talk Subject: Re: UUID's ( maybe OT) UUIDs with a datatype of uniquidentifier are indexed just as pk's - Original Message - From: Zac Spitzer [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:15 AM Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me is article id's... look at cfcomet for example... the article ids aren't user friendly, it reminds me of good old lotus notes and we all know how short urls are better than long one ( email wrapping for example ) not to mention that your database and CF load is much higher using long text pk's than with nice short numeric keys and your page size is increased a lot too.. just letting off steam. don't want to create a flame war or anything z __ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: UUID's ( maybe OT)
Right, though generally speaking, referencing an index on an integer or a longinteger column is faster than referencing an index on a 20 character varchar field... Of course, they're probably using something like verity that will index the filename regardless of the id in which case it's sort of moot, but still -- the fact that the integer is more efficient for the machine is really an afterthought -- the more important point is that it's easier and more efficient for _people_ to use... Isn't that the larger purpose for the machines in the first place? Making things easier? Isaac Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 The url would be indexed :) - Original Message - From: S. Isaac Dealey [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 1:12 PM Subject: RE: UUID's ( maybe OT) I don't really know much about most other vendors' cms, but this is one of the things I dislike about a number of cms that I've seen (from the outside anyway) ... I just don't see the need for a url like: http://www.metlife.com/Applications/Corporate/WPS/CDA/Page Generator/0,1674,P 249,00.html ( this is the signiature url-format of Vignette's StoryServer ) when a url like http://www.metlife.com/50598.html should suffice for just about anything, regardless of how much content you have. I could have fifty thousand pages in that site, or I could have fifty-BILLION pages in that site and it wouldn't matter, I could still use a reasonably simple url like this. I can't imagine those long content entry id's in StoryServer and the like help the software do its job quickly or efficiently either... And the really nice thing about using numbers is, not only are they short, but the length of the string only increases at 1/10th the rate of content increase, so the numbers stay small and easy for people to remember or write down or repeat to someone over the phone. As opposed to the 2 minute ordeal I would go through copying down a url like above on paper and double-checking to be sure it's correct. Try giving someone a url like that verbally -- ever worked technical support where you had to give someone a url over the phone so they could download a driver? Usually you're saddled by the requirements of your call center that you can't send anyone email, so copying and pasting the url is out of the question. And even with url's that are much simpler than this you often wind up with users having difficulty hearing or understanding it: http://www.metlife.com/applications/corporate/wps ... .. w - p as in paul - s as in sam ... slash .. c as in cat, d as in dog, a as in apple... PageGenerator ... p as in paul, a as in apple, g as in golf, e as in echo... Ten minutes later they have the url and your average call-time's gone through the roof. God forbid the person is hard of hearing or just plain computer illiterate. /rant Not that there isn't any place for UUID's ... A place they'd be useful? How about a system where incident or report tickets are input into a central repository but are being generated from multiple individual locations? ... sure... Generate a UUID at the location where the report or incident is created, along with a local numeric identity key. When you import the data from your multiple locations, you take in a location id, a local unique number, and a UUID -- someone searching the central repository can pick out an individual entry by entering a combination of a location id and local unique identifying number, or a UUID, or a unique number generated at the central repository. The UUID is the official or cardinal identifier, so if you're not able to retreive data from any of the other identifiers, the UUID is what you fall back on as the authoritative answer / identifier. So when someone at location a calls and says I need info on ticket #50 for location a, and you can't find the ticket, you ask them for the UUID and if the UUID doesn't exist, then they're just SOL. :) If it does exist, then you can determine if it's mislabelled ( the import mangled the location id or the local identifier ) and fix that problem. S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 but as a datatype in SQL Server 2000 wouldn't you imagine that m$ has made it so that the sql server engines running it are tuned to perform well with these? ..tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Zac Spitzer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 1:16 PM To: CF-Talk Subject: UUID's ( maybe OT) I am probably OT here, but I see so many people using UUID's when simpler normal numeric keys are better... a classic example for me
