|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Order By Primary KeyWere talking about millions of rows. The name of this field is TempID. I always want to sort by the TempID ascending....is that something that I even need to specify? When I query it in Query Analyzer it seems to always be sorted by the primary key ascending. Although this is what I want, will this ALWAYS be the case, or should I just throw an order by in there for good measure? Stored Proc: -------------------------------- @numberOfRows int, @startingID int set rowcount @numberOfRows Select * From tblList Where TempID > @startingID set rowcount 0 -------------------------------- Will this always work how I expect or should I add the "Order By TempID"? I am asking because I don't know if my Order By clause will slow it down. I'm sure I wouldn't notice if it was .0000000002 ms slower, but this would be good to know, especially if @startingID = 4,000,000 or the @numberOfRows is very large. I hope that all made sense. Read the BOL for more information under "Clustered Indexes":
"An index on the columns specified in the ORDER BY or GROUP BY clause may remove the need for the Database Engine to sort the data, because the rows are already sorted. This improves query performance." Didi you create them as Clustered keys ? HTH, Jens Suessmeyer. INeedADip wrote:
Show quote > I've got a table with an a primary key of type 'int' (auto The only way to guarantee the order of results is with an ORDER BY > incrementing). Were talking about millions of rows. > > The name of this field is TempID. > > I always want to sort by the TempID ascending....is that something > that I even need to specify? > When I query it in Query Analyzer it seems to always be sorted by the > primary key ascending. > Although this is what I want, will this ALWAYS be the case, or should > I just throw an order by in there for good measure? > > Stored Proc: > -------------------------------- > @numberOfRows int, > @startingID int > > set rowcount @numberOfRows > Select * From tblList Where TempID > @startingID > set rowcount 0 > -------------------------------- > > Will this always work how I expect or should I add the "Order By > TempID"? I am asking because I don't know if my Order By clause will > slow it > down. I'm sure I wouldn't notice if it was .0000000002 ms slower, but > this would be good to know, especially if @startingID = 4,000,000 or > the @numberOfRows is very large. > > I hope that all made sense. clause. If that column is your PK, you should already have a unique index on the column. If it's clustered, it will help with sorting. Keep in mind that sort operations are very costly. While the unique, clustered index on the PK column might eliminate the need for the sort, it is no guarantee. You still need the ORDER BY clause. You have a ton of basic mistakes and need to get an intro book on SQL.
Columns are not fields. An auto-increment can never be a relational key by definition because it is not an attribute of the entities modeled in the table. Tables by definition have no ordering. You are confusing an implementation with SQL and proper data modeling. If you want to be sure that you get your output in order, you need an ORDER BY clause. Years ago, SQL Server programmers got screwed up becuase they wrote code that assumed a GROUP BY clause would be done with a sort under the covers, so they did not write the ORDER clause. It blew up a ton of programs on the next release. Wow...guess I hit a nerve.
I'm sorry, I should have picked my words a little more carefully. I figured you would get the jist of it..... Why would auto-increment fields not be an attribute of the entities in the table? Isn't that one of the easiest ways to get a unique identifier for that set of data, making it a key attribute? "can never be a relational key"...I've never heard that argument. There are different schools of thought on using auto-increment fields as
keys. Personally, I tend to agree with Celko on this one. Auto-increment fields have nothing to do with the data in the table, they are an artificial way of creating uniqueness. A more meaningful key would suit my tastes. Using meaningful keys allows you to 1. Reuse the column name and data type in all tables, which makes joins more intuitive. Job.deptid = department.deptid is easier and more intuitive than job.Department = department.id 2. Use a key value that makes some sort of sense when you look at it. 3. Avoid redundancy in your table and insure normalization. Often when we have an auto-incremeneting key, there is another column or columns that also uniquely identify the row. However, there are many in the field (with as much experience as myself or Celko) that consider auto-increment keys a requirement in their tables. As for the terminology, do a search on celko and punch cards to see why he makes such an issue of it. As long as everone knows what you mean by "field" and "record" (and we do) I wouldn't lose any sleep over it. Show quote "INeedADip" <INeedA***@gmail.com> wrote in message news:eF8AOUEIGHA.2704@TK2MSFTNGP15.phx.gbl... > Wow...guess I hit a nerve. > I'm sorry, I should have picked my words a little more carefully. > I figured you would get the jist of it..... > > Why would auto-increment fields not be an attribute of the entities in the > table? > Isn't that one of the easiest ways to get a unique identifier for that set > of data, making it a key attribute? > > "can never be a relational key"...I've never heard that argument. > > So you guys are just refering to the name of the column?
I do have incrementing fields in 99% of my tables like AccountID, QueueID, CampaignID, ect... If that is what you guys are talking about, I agree.....anyways.... Thanks for educating me on the Order By, I was under the impression that if I used an index on the field, I could save some time by not using the Order By. And just to note...I'm wasn't asking this question as a general rule, but in this one case (this specific table) I was trying to save some time because the table is so large and I will only be getting chunks in ascending order EVERY TIME...but if it is not guaranteed, then I will add the "Order By". - Thanks >> I do have incrementing fields [sic] in 99% of my tables like AccountID, QueueID, CampaignID, etc. <,You do not even know that column and field ae TOTALLY DIFFERENT concpets !!?? Again, this is foundations, not he rocket scinece end of RDBMS. >> I was under the impression that if I used an index on the field [sic], I could save some time by not using the Order By. << YUou are liek me in an oerating room --you will kill people with thebest intentiuons. >> ascending order EVERY TIME...but if it is not guaranteed, then I will add the "Order By". <<You have never bothered to read a single book on SQL, have you? Standard, real SQL and not a hillbily dialect. Hi Jim,
I've got to take the bite and put the surrogate key side forward. If a natural key exists on the table (that isn't in reality a generated number in itself - for instance deptid would indicate its auto-generated some how), most keys in the natural world are actually a surrogate of some form or another. There are problems duplicating the natural key everywhere, especially if its a composite key; there is no difference in joining whether you use a surrogate key or a natural one to join. INeedADip - do a search on 'surrogate key' and 'identity' for some really good and extensive discussions on the benefits of the surrogate key approach. Tony. Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:uNTKWeEIGHA.376@TK2MSFTNGP12.phx.gbl... > There are different schools of thought on using auto-increment fields as > keys. Personally, I tend to agree with Celko on this one. Auto-increment > fields have nothing to do with the data in the table, they are an > artificial > way of creating uniqueness. A more meaningful key would suit my tastes. > Using meaningful keys allows you to > 1. Reuse the column name and data type in all tables, which makes joins > more > intuitive. > Job.deptid = department.deptid > is easier and more intuitive than > job.Department = department.id > 2. Use a key value that makes some sort of sense when you look at it. > 3. Avoid redundancy in your table and insure normalization. > Often when we have an auto-incremeneting key, there is another column > or > columns that also uniquely identify the row. > > However, there are many in the field (with as much experience as myself or > Celko) that consider auto-increment keys a requirement in their tables. > > As for the terminology, do a search on celko and punch cards to see why he > makes such an issue of it. As long as everone knows what you mean by > "field" and "record" (and we do) I wouldn't lose any sleep over it. > > > "INeedADip" <INeedA***@gmail.com> wrote in message > news:eF8AOUEIGHA.2704@TK2MSFTNGP15.phx.gbl... >> Wow...guess I hit a nerve. >> I'm sorry, I should have picked my words a little more carefully. >> I figured you would get the jist of it..... >> >> Why would auto-increment fields not be an attribute of the entities in >> the >> table? >> Isn't that one of the easiest ways to get a unique identifier for that >> set >> of data, making it a key attribute? >> >> "can never be a relational key"...I've never heard that argument. >> >> > > Thanks Tony.
I believe there was a fairly in depth discussion about this last week, although I purge my postings frequently and can't locate it. If I recall correctly, you were one of the folks involved in the discussion. Would you mind posting a link to it? Show quote "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message news:eyo318FIGHA.2912@tk2msftngp13.phx.gbl... > Hi Jim, > > I've got to take the bite and put the surrogate key side forward. > > If a natural key exists on the table (that isn't in reality a generated > number in itself - for instance deptid would indicate its auto-generated > some how), most keys in the natural world are actually a surrogate of some > form or another. > > There are problems duplicating the natural key everywhere, especially if its > a composite key; there is no difference in joining whether you use a > surrogate key or a natural one to join. > > INeedADip - do a search on 'surrogate key' and 'identity' for some really > good and extensive discussions on the benefits of the surrogate key > approach. > > Tony. > > -- > Tony Rogerson > SQL Server MVP > http://sqlserverfaq.com - free video tutorials > > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:uNTKWeEIGHA.376@TK2MSFTNGP12.phx.gbl... > > There are different schools of thought on using auto-increment fields as > > keys. Personally, I tend to agree with Celko on this one. Auto-increment > > fields have nothing to do with the data in the table, they are an > > artificial > > way of creating uniqueness. A more meaningful key would suit my tastes. > > Using meaningful keys allows you to > > 1. Reuse the column name and data type in all tables, which makes joins > > more > > intuitive. > > Job.deptid = department.deptid > > is easier and more intuitive than > > job.Department = department.id > > 2. Use a key value that makes some sort of sense when you look at it. > > 3. Avoid redundancy in your table and insure normalization. > > Often when we have an auto-incremeneting key, there is another column > > or > > columns that also uniquely identify the row. > > > > However, there are many in the field (with as much experience as myself or > > Celko) that consider auto-increment keys a requirement in their tables. > > > > As for the terminology, do a search on celko and punch cards to see why he > > makes such an issue of it. As long as everone knows what you mean by > > "field" and "record" (and we do) I wouldn't lose any sleep over it. > > > > > > "INeedADip" <INeedA***@gmail.com> wrote in message > > news:eF8AOUEIGHA.2704@TK2MSFTNGP15.phx.gbl... > >> Wow...guess I hit a nerve. > >> I'm sorry, I should have picked my words a little more carefully. > >> I figured you would get the jist of it..... > >> > >> Why would auto-increment fields not be an attribute of the entities in > >> the > >> table? > >> Isn't that one of the easiest ways to get a unique identifier for that > >> set > >> of data, making it a key attribute? > >> > >> "can never be a relational key"...I've never heard that argument. > >> > >> > > > > > > I think this is one of them....
http://groups.google.co.uk/group/comp.databases.theory/browse_frm/thread/337a747e526c5f47/776d2a8ccf940fe2?lnk=st&q=surrogate+key+rogerson+--celko--&rnum=2&hl=en#776d2a8ccf940fe2 but there are many, search on 'surrogate key' rogerson --celko-- Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:eIiy5BGIGHA.2212@TK2MSFTNGP15.phx.gbl... > Thanks Tony. > > I believe there was a fairly in depth discussion about this last week, > although I purge my postings frequently and can't locate it. If I recall > correctly, you were one of the folks involved in the discussion. Would > you > mind posting a link to it? > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:eyo318FIGHA.2912@tk2msftngp13.phx.gbl... >> Hi Jim, >> >> I've got to take the bite and put the surrogate key side forward. >> >> If a natural key exists on the table (that isn't in reality a generated >> number in itself - for instance deptid would indicate its auto-generated >> some how), most keys in the natural world are actually a surrogate of >> some >> form or another. >> >> There are problems duplicating the natural key everywhere, especially if > its >> a composite key; there is no difference in joining whether you use a >> surrogate key or a natural one to join. >> >> INeedADip - do a search on 'surrogate key' and 'identity' for some really >> good and extensive discussions on the benefits of the surrogate key >> approach. >> >> Tony. >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlserverfaq.com - free video tutorials >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> news:uNTKWeEIGHA.376@TK2MSFTNGP12.phx.gbl... >> > There are different schools of thought on using auto-increment fields >> > as >> > keys. Personally, I tend to agree with Celko on this one. > Auto-increment >> > fields have nothing to do with the data in the table, they are an >> > artificial >> > way of creating uniqueness. A more meaningful key would suit my >> > tastes. >> > Using meaningful keys allows you to >> > 1. Reuse the column name and data type in all tables, which makes joins >> > more >> > intuitive. >> > Job.deptid = department.deptid >> > is easier and more intuitive than >> > job.Department = department.id >> > 2. Use a key value that makes some sort of sense when you look at it. >> > 3. Avoid redundancy in your table and insure normalization. >> > Often when we have an auto-incremeneting key, there is another >> > column >> > or >> > columns that also uniquely identify the row. >> > >> > However, there are many in the field (with as much experience as myself > or >> > Celko) that consider auto-increment keys a requirement in their tables. >> > >> > As for the terminology, do a search on celko and punch cards to see why > he >> > makes such an issue of it. As long as everone knows what you mean by >> > "field" and "record" (and we do) I wouldn't lose any sleep over it. >> > >> > >> > "INeedADip" <INeedA***@gmail.com> wrote in message >> > news:eF8AOUEIGHA.2704@TK2MSFTNGP15.phx.gbl... >> >> Wow...guess I hit a nerve. >> >> I'm sorry, I should have picked my words a little more carefully. >> >> I figured you would get the jist of it..... >> >> >> >> Why would auto-increment fields not be an attribute of the entities in >> >> the >> >> table? >> >> Isn't that one of the easiest ways to get a unique identifier for that >> >> set >> >> of data, making it a key attribute? >> >> >> >> "can never be a relational key"...I've never heard that argument. >> >> >> >> >> > >> > >> >> > > >> a natural key exists on the table (that isn't in reality a generated number in itself - for instance deptid would indicate its auto-generated some how), most keys in the natural world are actually a surrogate of some form or another. << I use Dr. Codd's definition of a surrogate and not Rogerson's. Asurrogate is unseen like an index and is maintained by the system. I also disagree things like a dept_id are auto-generated. I have a few chapters in sevreal books about how to design the encoding and I avoid auto-increment because they cannot be verified and often cannot be validated agaisnt the restof the RDBMS. Abbreviation codes, numeric codes that match the accountign sytem, etc. >> There are problems duplicating the natural key everywhere, especially if its a composite key; t<< Not really. Do the math, look at word size, processor speeds, how thebetter VLDB products do surrogates, etc. Rogerson's definition is the same as Codd's....
At the implementation phase of the logical model I will place surrogate keys where they are needed, that is where there is a natural key, i will then use the surrogate keys as the foreign key references and as the API into the applications that the database supports. At no point will the user see this surrogate key value. Where a natural key does not exist then I will creaete my own auto-generated number, that will usually include the IDENTITY property because I don't feel the need to role my own, I will feed the value returned from the IDENTITY property into my check digit formula so it can be validated in case of corruption outside of the database. You will do exactly the same with dep_id, you use an auto-generated sequence and apply a check digit formula, the difference is that you will role your own because you don't use properitary features; having said that there is a sequence in the current SQL standard now anyway. > Not really. Do the math, look at word size, processor speeds, how the Yes there is - i really think it is time you actually sat down and worked it > better VLDB products do surrogates, etc. out, stop brushing these two fundementals problems with duplicating the natural key in every table and up and down the wire to the application... a) Network bandwidth increase because you have to send the bloated natural key and the entity description, with surrogate key, you simply send the surrogate and the entity description, the surrogate is passed back to the db. b) Memory, CPU cycles ALL increase SIGNIFICANTLY especially when you use the proper natural key rather than one of your coding schemes; after-all all you are doing is creating your own surrogate but it doesn't follow Codd's rules! c) When the natural key value changes you are stuff, you causes massive contention problems in teh database because of the huge multi-table transaction, you cause problems with the application because the application is referencing 'abc' and now in the database its 'abcd' - I just hope nobody adds another row with the natural key 'abc' because the application will go and update the wrong row! Those problems go away when you use the surrogate key because its read only. Also, you might want to check the market statistics as to which is the 'better VLDB product'. Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1138246726.872127.235870@g14g2000cwa.googlegroups.com... >>> a natural key exists on the table (that isn't in reality a generated >>> number in itself - for instance deptid would indicate its auto-generated >>> some how), most keys in the natural world are actually a surrogate of >>> some form or another. << > > I use Dr. Codd's definition of a surrogate and not Rogerson's. A > surrogate is unseen like an index and is maintained by the system. I > also disagree things like a dept_id are auto-generated. I have a few > chapters in sevreal books about how to design the encoding and I avoid > auto-increment because they cannot be verified and often cannot be > validated agaisnt the restof the RDBMS. Abbreviation codes, numeric > codes that match the accountign sytem, etc. > >>> There are problems duplicating the natural key everywhere, especially if >>> its a composite key; t<< > > Not really. Do the math, look at word size, processor speeds, how the > better VLDB products do surrogates, etc. > >> Why would auto-increment fields [sic] not be an attribute of the entities in the table? << BY DEFINITION, a key is a subset of attributes of an entity which makeeach instance unique. A relatioanl key exists in the eality of the data model before it is modeled in the RDBMS. This is one of many reasons that columns are not fields -- this is a matter of RDBMS versus file physical systems. An auto-increment fields [sic] depends on the PHYSICAL state of the hardware at the time of insertion of a PHYSICAL record (NOT the entity modeled). That ain't RDBMS. Not even close on a good day. Duh! It is way to mimic a sequential file in SQL if you misse dthew whole idea of RDBMS and want to have locators (pointers, record numbers, etc.). If you want an analog, the VIN number on a car is the relational key because it persists and can be validated within itself and verified externally But the current park space number is an auto-increment field depends on your arrival time. >> "can never be a relational key"...I've never heard that argument. << Then you never read Dr. Codd and all -- repeat ALL-- of the RDBMSliterature for the 30+ years that followed him? Geesh! What I am saying is at that kind of FUNDAMENTAL level. How did you miss it?? Is the Pope Catholic? >> Isn't that one of the easiest ways to get a unique identifier for that set of data, making it a key attribute? << Yes, and that is why morons do it!! Duh!! If you do not have toproduce **correct results**, the easiest way to produce an answer is to output 42 everytime. I get $1000 to $2000 day to clean up crap where someone took the easiest way and someone died. I am VERY SERIOUS about the dying part. I consult for medical relief organixzation whose databses are done by well-meaning and stupid vounteers. Bad fatabase design kills children in African war zones. by messing up shipments. But we can be grateful that the code was easy for you to write. Yeah. Do you have any sense of proifessionalism?? > Then you never read Dr. Codd and all -- repeat ALL-- of the RDBMS The 30+ years is worthless if better practices and methods come along in the > literature for the 30+ years that followed him? Geesh! What I am > saying is at that kind of FUNDAMENTAL level. How did you miss it?? > Is the Pope Catholic? meantime (which they have). The analogy is, listen to Ford, 100+ years that followed him? Was he right, was petrol the best and only way to run your motor car? Stop relying on doctorine and get with the times, database products have been evolving for the good because at last now we can do a lot more without resorting to hundreds of lines of complex 3gl code. Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1138245391.812920.166410@o13g2000cwo.googlegroups.com... >>> Why would auto-increment fields [sic] not be an attribute of the >>> entities in the table? << > > BY DEFINITION, a key is a subset of attributes of an entity which make > each instance unique. A relatioanl key exists in the eality of the > data model before it is modeled in the RDBMS. This is one of many > reasons that columns are not fields -- this is a matter of RDBMS versus > file physical systems. > > An auto-increment fields [sic] depends on the PHYSICAL state of the > hardware at the time of insertion of a PHYSICAL record (NOT the entity > modeled). That ain't RDBMS. Not even close on a good day. Duh! It > is way to mimic a sequential file in SQL if you misse dthew whole idea > of RDBMS and want to have locators (pointers, record numbers, etc.). > > If you want an analog, the VIN number on a car is the relational key > because it persists and can be validated within itself and verified > externally But the current park space number is an auto-increment > field depends on your arrival time. > >>> "can never be a relational key"...I've never heard that argument. << > > Then you never read Dr. Codd and all -- repeat ALL-- of the RDBMS > literature for the 30+ years that followed him? Geesh! What I am > saying is at that kind of FUNDAMENTAL level. How did you miss it?? > Is the Pope Catholic? > >>> Isn't that one of the easiest ways to get a unique identifier for that >>> set of data, making it a key attribute? << > > Yes, and that is why morons do it!! Duh!! If you do not have to > produce **correct results**, the easiest way to produce an answer is to > output 42 everytime. I get $1000 to $2000 day to clean up crap where > someone took the easiest way and someone died. I am VERY SERIOUS about > the dying part. I consult for medical relief organixzation whose > databses are done by well-meaning and stupid vounteers. Bad fatabase > design kills children in African war zones. by messing up shipments. > > > But we can be grateful that the code was easy for you to write. Yeah. > > > Do you have any sense of proifessionalism?? > >> the analogy is, listen to Ford, 100+ years that followed him? Was he right, was petrol the best and only way to run your motor car? << False analogy. The RDBMS is an abstract model, not an implementation.The abstract idea is moving people in vehicles -- horse-drawn, internal combustion, diesel, etc, are the engine implementations. Did you throw out Algebra when we got pocket calculators? Practices are not the issues; the issue is the model. Stop relying on current fads the last release of the only poroduct you known and get back to mathematical foundations. So why do you follow the standard? Do you not adopt new features introduced
into the standard? How do we differ? If something better than algebra came along then we would adopt that; there are countless things throughout history where we have done that. > Stop relying on current fads the last release of the only poroduct you I'm translating that as, stop using properitary features.> known and get back to mathematical foundations. Why, my client has paid good money for the product and wants to get the most value from their investment. They also want an efficient simple solution that can be easily maintained, they don't want ten's of hundreds of lines of code just because the ego requires portability and has such a narrow vision that prohibits them from seeing outside their little universe. There is now a single statement in SQL 2005 that allows you to do grouped value concatenation, it would take cursors, dozens of lines and not scale to do it in standard SQL; and the argument that formatting should be done in the front end does not wash with any experienced client server developers of which I do not classify you belonging to that group. 30+ years is meaningless if you are not willing to learn, you are stuck in the 80's model of programming and architecture, you consistently fail with implementation, directly trying to implement logical models is not correct. Wake up, there are people in this community with 3 years experience that can run rings round you. Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1138508750.839356.160000@f14g2000cwb.googlegroups.com... >>> the analogy is, listen to Ford, 100+ years that followed him? Was he >>> right, was petrol the best and only way to run your motor car? << > > False analogy. The RDBMS is an abstract model, not an implementation. > The abstract idea is moving people in vehicles -- horse-drawn, internal > combustion, diesel, etc, are the engine implementations. > > Did you throw out Algebra when we got pocket calculators? Practices > are not the issues; the issue is the model. > > Stop relying on current fads the last release of the only poroduct you > known and get back to mathematical foundations. > >> So why do you follow the standard? Do you not adopt new features introduced into the standard? How do we differ? <<I wait until the new Standard features are common to many SQL engines, so I can port my code. You advocate writing code that is soooo proprietary that it cannot port or be read easily by anyone who knows the Standard language. >> and the argument that formatting should be done in the front end does not wash with any experienced client server developers of which I do not classify you belonging to that group. << LOL! Where the hell do you think that the tiered architecture (AKAclient server) came from? One of the probems with you kids that have less than 20 yesrs of IT experience is that you do not remember WHY those rules were made, so you create the same old problems over and over! Read Dijkstra' s remarks on this pattern. Oh, do you know who Dijkstra is/ Codd,? Date? DeMarco? Yourdon? Do you have any knowledge of your trade, or only what Bill Gates tells you in the MS Village? > LOL! Where the hell do you think that the tiered architecture (AKA So I'm still a kid even though I have 20 years experience, I suppose that > client server) came from? One of the probems with you kids that have > less than 20 yesrs of IT experience is that you do not remember WHY > those rules were made, so you create the same old problems over and > over! just doesn't fit with your argument model of the more years you have the better you are. Well, pop your ego; there are people on here with 3 years experience that run rings round you. The first 7 years of my career was spent developing mainframe applications using PL/1 with initially VSAM then a little bit of DL/1 (like XML) and then CICS/DB2, I then moved into client/server programming with Oracle and then later into SQL Server - if you want a full list then google my biography. I am not the one who sits there writing books and papers, I am out there getting real experience with real business problems - get out of the class room! I fully know the rules and if a rule says pass 100MBytes of data out of your SQL Server to your middle or client tier while you only need 10KBytes of that (example: paging) then that rule is wrong and I don't care who wrote it - the rule has to be changed because the development environment and practices, hardware has changed! You cannot remain static, you are stuck in the 80's and earlier coding styles and ideas; no wonder your ideas do not scale in todays applications and problems. Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1138584155.987590.13790@f14g2000cwb.googlegroups.com... >>> So why do you follow the standard? Do you not adopt new features >>> introduced > into the standard? How do we differ? << > > I wait until the new Standard features are common to many SQL engines, > so I can port my code. You advocate writing code that is soooo > proprietary that it cannot port or be read easily by anyone who knows > the Standard language. > >>> and the argument that formatting should be done in the front end does >>> not wash with any experienced client server developers of which I do not >>> classify you belonging to that group. << > > LOL! Where the hell do you think that the tiered architecture (AKA > client server) came from? One of the probems with you kids that have > less than 20 yesrs of IT experience is that you do not remember WHY > those rules were made, so you create the same old problems over and > over! > > Read Dijkstra' s remarks on this pattern. Oh, do you know who Dijkstra > is/ Codd,? Date? DeMarco? Yourdon? Do you have any knowledge of > your trade, or only what Bill Gates tells you in the MS Village? >  |
|||||||||||||||||||||||
Other interesting topics