 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / General / Other SQL Server Topics / July 2005Stored Procs vs VIEWS: Seeking Comparison
Every article which I've seen proposing Stored Procedures makes the same comparison: Stored Procs are faster than submitted SQL because Stored Procs are precompiled. Fine, but there's a third alternative, which I haven't seen mentioned at all. How do Stored Procedures compare with VIEWS? Now we have some pretty complex SQL statements (sample below) and it's obvious to me that having this precompiled into a Stored Proc is much more efficient than submitting this repetitively as a SQL request. But what if this is defined in a database VIEW? With this scenario, the submitted SQL is greatly simplified to SELECT * FROM VMSGRECIPIENTS2 WHERE ... How does this now compare with the equivalent Stored Procedure which would contain the same SQL definition as the VIEW, but which would pass in the selection criteria as parameters, rather than as a WHERE clause? Do you know of any articles which explictly compare Stored Procs to their equivalent VIEWS? (Of course I am aware of the many things which can be done via Stored Procs, which cnanot be done via VIEWS. That is not my issue. My issue concerns read-only operations which can be performed either via a VIEW or a Stored Proc. I'm formulating a database design policy and I'd be very grateful for any guidance with this specific issue.) Thank you very much for your advice. - Joe Geretz - CREATE VIEW "VMSGRECIPIENTS2" ( Columns... ) AS SELECT Columns... FROM MSGRECIPIENTS LEFT JOIN MSGMASTER ON (MSGMASTER.MSGID = MSGRECIPIENTS.MSGID) LEFT JOIN MSGROUTING ON (MSGROUTING.MSGID = MSGRECIPIENTS.MSGID) AND (MSGROUTING.ROUTINGID = MSGRECIPIENTS.ROUTINGID) LEFT JOIN PERSON ON (MSGMASTER.PERSONID = PERSON.PERSONID) LEFT JOIN USERGROUPS ON (USERGROUPS.GROUPID = MSGRECIPIENTS.ENTITYID) LEFT JOIN GROUPMEMBERSHIP ON (GROUPMEMBERSHIP.GROUPID = USERGROUPS.GROUPID) LEFT JOIN MSGPRIORITIES ON (MSGROUTING.PRIORITYID = MSGPRIORITIES.PRIORITYID) LEFT JOIN MSGSUBJECTS ON (MSGROUTING.SUBJECTID = MSGSUBJECTS.SUBJECTID) LEFT JOIN DOCUMENTS ON (MSGMASTER.ATTACHMENTS = DOCUMENTS.DOCUMENTID) GO > Every article which I've seen proposing Stored Procedures makes the same > comparison: Stored Procs are faster than submitted SQL because Stored > Procs are precompiled. Fine, but there's a third alternative, which I > haven't seen mentioned at all. How do Stored Procedures compare with > VIEWS? Views are not used for improving performance (unless you are talking about indexed views or distributed partitioned views). Even there, you can use stored procedures to access the view, instead of just saying "SELECT * FROM ViewName" in your application code. A common misconception is that a view somehow caches or stores the data that it returns, and this is not the case (again, in "normal" views). Typically, views are used to reduce the complexity of a table's schema or the relationship of multiple tables, for example a view called CustomerData might include the customerID from Customers, the primary address from the CustomerAddresses table, and the most recent order from the Orders table. Now, a user writing a SELECT statement (or a stored procedure that uses a SELECT statement) doesn't have to understand all of those relationships. Another typical purpose for a view is to restrict access to certain data. For example, in the Employees database, there is probably at least one table with 401k/salary information that you don't want exposed to all users. So you might have very restricted permissions on the table itself, and then create a view that leaves out those columns, and give more ready access to that view so that the average user can still get a list of all the employees, but won't be able to see which ones make more money... > read-only operations which can be performed either via a VIEW or a Stored > Proc. I think that's a very narrow and limited view, no pun intended. You can certainly use both -- stored procedures for performance/encapsulation, and views for schema/query/relationship simplification and/or security. Thanks Aaron, for your enlightening reply. > I think that's a very narrow and limited view, no pun intended. You can > certainly use both -- stored procedures for performance/encapsulation, and > views for schema/query/relationship simplification and/or security. Actually, I'm trying to be as broadminded as possible. However, our team of half-a-dozen developers is in a position where we need to impose standards. We can't simply allow developers to individually adopt whatever approach they happen to prefer. So, in the sense that standards are a limiting factor, you are correct; that's what I'm trying to do. However, I don't intend to be fanatical by any means. Aside from the performance issue, VIEWS provide a few significant advantges: 1. They are flexible and can easily accommodate any WHERE clause. 2. They are absolutely transparent in terms of being READ-ONLY operations 3. They are comprised of ANSII SQL which is portable between database vendors. Neither of these are true of Stored Procedures. For a Stored Proc to be flexible, it must implement logic to determine which parameters are being supplied. And a Stored Proc which returns a recordset might be subsequently modified to update data, in a way which might not be obvious to maintenance programmers. And Stored Proc dialect is very often vendor specific, rendering the Stored Proc non-portable. I'm thinking of imposing the following standard: My Preferred Policy: --------------------- 1. READ-ONLY operations are performed via VIEWS 2. UPDATE operations performed via Stored Procs As opposed to: Techie Performance Policy: ---------------------------- 1. All operations performed via Stored Procs Although, if someone could demonstrate to me that Stored Procedure performance is significantly greater than that which is provided by a similar VIEW, I might feel that compelling enough to shift from My Preferred Policy to implement all operations via Stored Procedures (the Techie Performance Policy). So far, I'm not at all convinced that this is the case, or that even if it were, that the performance benefit would outweigh other considerations. If I understand you correctly, you feel that my preferred policy is reasonable? Thanks, - Joe Geretz - >> Every article which I've seen proposing Stored Procedures makes the same >> comparison: Stored Procs are faster than submitted SQL because Stored [quoted text clipped - 31 lines] > certainly use both -- stored procedures for performance/encapsulation, and > views for schema/query/relationship simplification and/or security. >> My Preferred Policy: >> ... >> As opposed to: >> Techie Performance Policy: Joseph, Joseph, Joseph.... Your use of the word "Techie" has a few possible meanings - none of which I think are positive. "My policy" vs "Techy policy" suggests that you are not very technically literate (somewhat, but not very strong here), but you are also trying to impose your views on people who are very technically literate (at least moreso than yourself). That's much like a hospital administrator (MBA type with no med school background) telling the doctors how to operate on the patients. You will soon be resented if you are not already resented by your "techie" subordinates as YOUR own fears and lack of expertise in THEIR knowledge domain comes to limit what they do in some rather rather uninformed ways (ininformed as defined by your intentions). There are other ways to implement standards. Trying to go to more restrictive technologies, which is apparently why you like VIEWS so much (misguided as your perception is), is a very Ludite thing to be doing (look it up - it will describe your tendencies). Rather than trying to control your developers and DBAs, why not ASK THEM (who know way more than you do in their respective knowledge domains) for THEIR IDEAS for streamlining things and for imposing standards. Perhaps they will suggest peer code reviews, a department-wide standard for stored procedures AND views where each is appropriate, etc. These people know how to do their job. They need someone in your position to FACILITATE communication and COORDINATE development of standards amongst them; NOT limit what and how they do things in significant and rediculous ways (like coming up with mandate described in your My Preferred Policy). If you don't trust your developers and feel you need to control them in order to compensate for your lack of expertise, then perhaps it's time for you to read the book, "Becoming a Technical Leader" by Geral M. Weinberg. -F > Thanks Aaron, for your enlightening reply. > [quoted text clipped - 88 lines] >> certainly use both -- stored procedures for performance/encapsulation, >> and views for schema/query/relationship simplification and/or security. Hi Frankie, > coming up with mandate described in your My Preferred Policy). If you > don't trust your developers and feel you need to control them in order to > compensate for your lack of expertise, then perhaps it's time for you to > read the book, "Becoming a Technical Leader" by Geral M. Weinberg. I guess that someone who makes gross assumptions about another individual without having anywhere near a sound basis for making these assumptions is probably the last person to advise me on becoming any sort of leader, technical or otherwise. With almost two decades of development work behind me, I'm in an excellent position to *balance* the logistics of team development with the technical realities of the environment in which we operate. And for the record, I am proud to call myself a Techie. From my perspective, I'd be more likely to use the term Paper-Pusher as a pejorative. Thanks for the free advice. I'm sure it's worth every penny! - Joe Geretz - >>> My Preferred Policy: >>> ... [quoted text clipped - 124 lines] >>> certainly use both -- stored procedures for performance/encapsulation, >>> and views for schema/query/relationship simplification and/or security. Well put, Joe. I don't think that there is as much of a performance benefit to stored procedures as there used to be in earlier versions of SQL Server, so performance is not really an issue. However, your argument for portability as an decision factor in using Views vs Stored Procs is betrayed by your own personal policy; if you're using procs to INSERT or UPDATE data, then there is no guarantee that those same procs will run on any other database server either. You may have to rewrite them as well, so apart from saving yourself the keystrokes on your SELECT procedures, you haven't really gained anything by NOT using stored procedures for SELECT statements (in regards to portability). <snip> Dou you know what is happening in GetCustomers? I don't. Is any data updating taking place? Who knows? But if you say SELECT * FROM CustomersVIEW I guarantee that no updating is taking place. </snip> I would have thought that a VB programmer (or is it developer, or Techie, or architect? :) ) would have more appreciation for the whole "black box" approach to a stored procedure; I agree that it's a bit of a crossover of business logic into the data tier, and that may be enough for the theorists to HATE stored procedures, but unless you're willing to fully develop your business logic tier in between your application and your data layer, stored procedures do give you some flexibility and code re-use without passing straight SQL from your app. If you write stored procedures that use vendor-specific SQL, you can optimize the performance of your application on that database platform. In other words, your app may SMOKE on SQL Server, and not run at all on Oracle. Your competitor may have an app that runs OK on either platform; which is better for your potential customers? The best scenario would be for you to invest not in a portable option, but in different versions of your application that are optimized for their respecitive database platforms. Much more expensive to implement, but the ideal solution. I guess if you're concerned about portability, I would choose neither view nor stored procedure; instead, I would probably build a map within your business logic tier that maps the appropriate application objects and methods to the correct data entities (you could use views to simply the schema, but if you're inserting and updating tables, why bother?). You'll still be passing complex SQL statements from this middle tier to your data source (without the potential gain of database-specific optimization), but your data source would be hidden from the application (and thus more portable), and your business logic would be isolated from your datasource. /nothing more to say; just pointing out the obvious. //not an OOP developer, but I eat lunch with them. ///I like slashes.... Stu Hi Stu, > portability as an decision factor in using Views vs Stored Procs is > betrayed by your own personal policy; if you're using procs to INSERT > or UPDATE data, then there is no guarantee that those same procs will > run on any other database server either. Well, that's the difference between a decision factor and a decision. Decisions are based on a number of factors which are often mutually contradictory. There are two options: 1. Don't make any decision. (I've seen this approach to often in corporate settings ;-) 2. Make the decision which accommodates the most important factors. I've taken approach #2. I did state above that portability was not my #1 factor. Although it is *a* factor and my approach is valid. I can either end up with 100 stored procedures or 50 views and 50 stored procedures. Although the latter isn't the perfect migration scenario, it's a much better position than the former. > "black box" approach to a stored procedure; I agree that it's a bit of > a crossover of business logic into the data tier, and that may be That's it in a nutshell. I did comment above in this thread about my preference for UI/Business & Data tiers over UI & Business/Data tiers. - Joe Geretz - > Well put, Joe. > [quoted text clipped - 51 lines] > > Stu > 1. Don't make any decision. (I've seen this approach to often in corporate > settings ;-) [quoted text clipped - 5 lines] > the latter isn't the perfect migration scenario, it's a much better position > than the former. so what is your #1 factor? So far all I've gotten from this chain is that it ain't portabilty, and it ain't performance. If it's your adherence to the design model of seperating business logic from the data tier AND the UI tier (which realistically translates into potability as a decision factor), then your policy also doesn't meet that requirement. You're still mucking around in the database with half your code, and why is that better than doing all of your code in the database (or none of it)? If your #1 factor is to have a standard in place that you and your developers can live with, that's OK. From what I've gathered here, you make the decision, and that should be enough reason to implement it (and to expect adherance). You don't need approval from me or anyone else; it's the bottom line that matters, and if "Your Personal Policy" helps you get a good product out the door that makes money for your company, who cares if you're logically consistent in your reasoning behind that policy? Granted, it's not my shop. And it's really easy for me (and the others) to arm-chair quarterback (but that's what you asked for when you posted to this newsgroup); I'm just pointing out the logical weaknesses in your argument, not the practical ones (and, to be fair, most arguments for using only stored procedures suffer from similar logical weaknesses). From a practical perspective, I think the idea of a standardized development policy is a great idea, and the requirement that you're suggesting is not onerous. I just think that the reasons you've given for deciding to implement said policy have either a) not been clearly stated, b) misinterpreted by me, or c) failed to lead to the logical conclusion that using views is prefereable to a stored procedure. I think from an n-tier design perspective, I'm leaning more toward removing business logic from the database altogether, and relying on Business Objects to map and interface with the data source; however, from a practical perspective, I'm uncomfortable with passing raw SQL statements over the wire between my business objects and my database. Not sure why, but I am. I'd be more likely to continue to use stored procedures to SELECT, INSERT, UPDATE and DELETE from my tables/views. May not be logical, but it works for me. :) Stu > so what is your #1 factor? There is no single overwhelming #1 factor as such. (does there always have to be?) There are a number of factors which I consider: Listed in alphabetic order: * Ease of Development * Ease of Maintenance * Performance * Portability > So far all I've gotten from this chain is > that it ain't portabilty, and it ain't performance. Well, actually it's more of a compromise between the considerations listed. I suppose, some might order the factors above into a list; #1, #2 and #3 and #4 and then choose a strategy optimized for Factor #1, and the heck with the other issues. In this case, I don't see any one issue as being so overwhelmingly positive and I don't see any one approach as being so overwhelmingly detrimental. Which is why I'm happy with a compromise approach. Unfortunately, my world doesn't consist exclusively of absolutes. > If your #1 factor is to have a standard in place that you and your > developers can live with, that's OK. From what I've gathered here, you [quoted text clipped - 4 lines] > company, who cares if you're logically consistent in your reasoning > behind that policy? Up until now, I've found that making good decisions contribute toward the development of a good product, far more effectively than making bad decisions do. (And I've unfortunately seen some pretty bad decisions which have had absolutely detrimental effects on products I've worked on in the past.) So it's information, rather than approval, which I am seeking. > Granted, it's not my shop. And it's really easy for me (and the > others) to arm-chair quarterback (but that's what you asked for when > you posted to this newsgroup); No, not exactly, see my next comment. > I'm just pointing out the logical > weaknesses in your argument, not the practical ones (and, to be fair, [quoted text clipped - 6 lines] > the logical conclusion that using views is prefereable to a stored > procedure. Or maybe you're presuming a question which I haven't actually asked. I asked for some basic points regarding the pros and cons of VIEWS, Stored Procs. What I haven't asked for is for others to supply conclusions based on these basic points. Because the technical points are only half (maybe even less than half) the equation. The other parts of the equation, which we haven't delved into, are the nature of the application, the development group, the long-term and short-term business goals, and a whole host of other relevant factors. So without all this information in hand, how would you expect to come up with a suitable solution? Indeed, it would be downright unreasonable of me to expect you to come up with a suitable solution for my specific situation, which is why I haven't asked for one. I have specifically NOT asked for others to fomulate my policy for me. A, it would be simplistic to assume that this is the sort of thing that we could do effectively via one thread on a newsgroup, and B, that's what they pay me for! :-) So if you see 'logical weaknesses' chalk it up to the fact that you're not in possession of *all* the facts in my scenario, nor would I presume to burden you with all of them. Although, for the purpose of discussion, we've touched on some points and I thank you very much for your input. But we certainly haven't by any stretch of the imagination gone through every single factor which is under consideration. > I think from an n-tier design perspective, I'm leaning more toward > removing business logic from the database altogether, and relying on [quoted text clipped - 4 lines] > procedures to SELECT, INSERT, UPDATE and DELETE from my tables/views. > May not be logical, but it works for me. There ya go! > :) Thanks for your insights! - Joe Geretz - > > so what is your #1 factor? > [quoted text clipped - 7 lines] > * Performance > * Portability [snip rest] Ease of Development - My money would be on Stored Procs accross the board - that way the people interfacing only have one route into the database that they have to follow - rather than going "Now, what am I doing here? If I'm reading data, I have to access the database in this manner, but if I'm updating, I have to access the database in a different manner" Having said that, the decision is fairly automatic for me - I construct the tables for my database, then run "The DOG" against the database. The DOG is an in-house product that runs through the schema and constructs a class for each table, along with a number of stored procs - for read, write (which will either insert or update), delete and for searching/traversing foreign key relationships, etc. I generally only have to write a few stored procs myself - for instance, a complex search which isn't based on a Primary or Foreign key. Calling the stored procs is encapsulated in the classes, so my only real contact with the database, so far as my application is concerned, is to pass the DOG Layer a connection string during startup. It's working fairly well. Views? We have a few on most databases - mostly to assist with ad-hoc queries that we have to run from QA when someone is asking questions that aren't answered by our MI system. Just my two-penneth Damien (remove the crossposts to other groups) >> so what is your #1 factor? > [quoted text clipped - 7 lines] >* Performance >* Portability Hi Joe, If I understand the discussion so far correctly, this is about the choice between a) stored proc (that might use the tables directly or use a view - or both) for changes, but views for selecting (client submits ad-hoc queries against the views), or b) stored proc (that might use the tables directly or use a view - or both) for changes AND selecting; select procs support parameters for different seaarches). Here are my opinions on the factors you mention. >* Ease of Development Switching from one approach to another will always incur a learning curve, but in the long run, stored proc's only wins. This gives you the ability to let each programmer do what he can do best. Those specialized in the DB side get to write the stored procs, those specialized in frontend stuff need not try to get their head around SQL. Also, you only need one kind of interface between front-end and DB; the other approach requires coders to be able to code a stored proc call AND to code an ad-hoc query. >* Ease of Maintenance Again: stored procs only wins.. The arguments above apply to maintenance as well. An extra argument is that you need to search through less code if unexpected results are returned. Run the stored proc that should have been executed with the parameters that should have been supplied. If the results are as desired, go and debug the frontend code. If they are not, go and debug the stored proc. In the stored procs + views approach, the fault might be anywhere: the view itself might be wrong, or the where clause tacked onto it in the front-end code, or the interface might handle data badly - or you might even find that the particular combination of view definition + where clause triggers some obscure SQL Server bug. >* Performance Another point in favor of stored procs. As explained in my earlier message, there is no notable difference **IF** (and only if) the queries issued by the front-end code are good. But don't forget that the DBA has much more control over stored procs than over ad-hoc queries. What will you do if the performance degrades? With storeed procs only, it is relatively easy to pinpoint the procedure that causes the trouble, then take steps to correct it (either rewrite the proc or change the indexes). Locating the reason of the slowdown will be harder if various queries against the various views are being sent to the server - and once you find it, it'll also take more effort to correct it. Plus, since the queries are written by people not specialized in SQL Server, there is a higher chance of getting inefficient queries. >* Portability And yet another point for the stored procs. Yes, you might have to rewrite the stored procs. But since there is a well-defined interface between front-end and back-end, that's it - the front-end doesn't have to change a bit. (Well, okay - the methods used to connect to the database, call the proc and receive the results might change). There are also some other factors that you didn;t mention, but that I think need to be taken into account as well * Flexibility Here, the views are the great winner. So what, if some goofy suit suddenly decides that he wants a report of all employees with age + shoe size > SQRT(salary) / 10? Just pop the appropriate WHERE clause in a standard execute-query-and-print-results program, run it and you're done. With stored procs, you'll either have to get the DBA to add a new search parameter to the read_employees proc first, before the frontend coder can write and run the program - and then he'll find out that there's been a miscommunication about the data type of the new parameter, so he'll have to change it yet again. Or you have to use the general read_all_employees proc, cursor through the results, discard all unwanted rows to list the few matching ones - probably slowing down the complete system for all other users while the program is running. * Scalability The two approaches don't differ much here. But remember the potential pitfalls listed under performance - if a system performs bad, it'll definitely NOT scale. Oh, and using stored procs only might also give you more control over the order in which tables are accessed - very important in heavily used systems to minimize the chance of deadlocks. Best, Hugo  Signature(Remove _NO_ and _SPAM_ to get my e-mail address) >(remove the crossposts to other groups) *cough* Well, I did *intend* to remove the crossposts.... Best, Hugo Signature(Remove _NO_ and _SPAM_ to get my e-mail address) Hi Hugo, I just can't see how Stored Procs can be considered the winner in terms of ease of development / maintenance. The software IDE (in our case VB) provides Intellisense, Real-time syntax checking, a full debugging environment including break, edit and continue, as well as a whole host of other facilities. The Stored Procedure development medium is more like NotePad - it doesn't provide any of these features. I'm not considering the raw SQL as part of this analysis, indeed we like to keep SQL abstracted out of our software layer as much as possible. Which is why we use VIEWS to provide a layer of indirection between the software and the base tables, and hide the complexities of the relationships between physical tables. But when it comes to 'added-value processing' i.e. business logic, we're getting to a complexity whic I feel is best implemented in software, rather than in the database, at least from an ease of development / maintenance perspective. - Joe Geretz - > (remove the crossposts to other groups) > [quoted text clipped - 100 lines] > > Best, Hugo > But when it comes to 'added-value processing' i.e. business logic, we're > getting to a complexity whic I feel is best implemented in software, rather > than in the database, at least from an ease of development / maintenance > perspective. This statement is only true if by business logic, you don't mean business rules. Business rules are constraints. Constraints should be part of the database, not part of an application. If constraints are enforced in applications, then all of those applications must enforce the constraints with the exact same logic, and no update can be allowed to occur outside of those applications. Even stored procedures must include the same constraint logic. Every update path must enforce all of the constraints. To me, it doesn't make any sense to have a whole lot of duplicate code in a system to enforce constraints, because maintenance is much more difficult. If a stored procedure can update a table, and a middleware object can update a table, then if a business rule changes, you must change the middleware object and the stored procedure. Failure to change both can allow incorrect information to be stored in the database. > Hi Hugo, > [quoted text clipped - 120 lines] > > > > Best, Hugo >Hi Hugo, > >I just can't see how Stored Procs can be considered the winner in terms of >ease of development / maintenance. (snip) Hi Joe, Well, I don't think I can explain it better than I already did. (Except that I now see that I forgot to include the argument that it's harder to make crossreferences and do impact analysis if the code is spread out over more platforms). I'm not on a mission to convince you (or others) of my views. You asked for other people's thought on this issue, I gave you mine. I also gave you the reasons for my opinions. Now, it's up to you to either change your mind, or not. As you already said in another message: making the final decision is what YOU are paid for! ;-) Best, Hugo Signature(Remove _NO_ and _SPAM_ to get my e-mail address) Joe, My apologies... it's actually spelled "Luddite" (two 'd's not one). Cheers! > Hi Frankie, > [quoted text clipped - 150 lines] >>>> performance/encapsulation, and views for schema/query/relationship >>>> simplification and/or security. >> My Preferred Policy: --------------------- 1. READ-ONLY operations are performed via VIEWS 2. UPDATE operations performed via Stored Procs << I think you got it. My only warning would be to make sure that the VIEWs make sense as tables and have a good name. When you write the procedures, follow basic software engineering practices. T-SQL is proprietary, but you can write it so that it is portable (i.e translated to the next dialect without a lot of pain). Hi Celko, Thanks for your reply. > proprietary, but you can write it so that it is portable (i.e > translated to the next dialect without a lot of pain). Do you know of any articles which discuss this aspect of writing T-SQL for maximum portability? Thanks, - Joe Geretz - >>> My Preferred Policy: > --------------------- [quoted text clipped - 6 lines] > proprietary, but you can write it so that it is portable (i.e > translated to the next dialect without a lot of pain). Turn on the FIPS Flagger to get warnings about proprietary code. If you learn Standard SQL from the start, you do not think about the propprietary stuff; likewise, if you learn T-SQL dialect from the start, you do not think about the Standard SQL syntax. There are some tools like Swissql that will translate SQL dialects for you. > Turn on the FIPS Flagger to get warnings about proprietary code. Don't use the FIPS flagger. It is more or less useless in SQL Server 2000. I haven't got any official reply, but I have this feeling that it wasn't updated between 7.0 and 2000. There are a bunch of things that it misses. Use the mimer validator instead. SignatureTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ Blog: http://solidqualitylearning.com/blogs/tibor/ > Turn on the FIPS Flagger to get warnings about proprietary code. > > If you learn Standard SQL from the start, you do not think about the > propprietary stuff; likewise, if you learn T-SQL dialect from the > start, you do not think about the Standard SQL syntax. There are some > tools like Swissql that will translate SQL dialects for you. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.