tag:blogger.com,1999:blog-8884584404576003487.post2461645570402247419..comments2024-02-29T09:43:12.251-05:00Comments on ORACLENERD: Application Developers vs. Database Developers: Part IIoraclenerdhttp://www.blogger.com/profile/12412013306950057961noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-8884584404576003487.post-75489668000219515452009-01-28T14:34:00.000-05:002009-01-28T14:34:00.000-05:00or:select count(*) from companiesIhaveworked where...or:<BR/><BR/>select count(*) from companiesIhaveworked where postgresql = "good enough" or mysql = "good enough"<BR/><BR/>result = all<BR/><BR/>or better yet:<BR/><BR/>select count(*) from companies99%ofDevsHaveWorkedAt where postgresql = "good enough" or mysql = "good enough"<BR/><BR/>result = all<BR/><BR/>Of course, this assumes that Oracle somehow buys you something that you don't get with a PostgreSQL. Beyond the gimmicks like AQ, I'm not sure that's a valid assumption.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-68328468861815188822009-01-28T13:28:00.000-05:002009-01-28T13:28:00.000-05:00select count(*) from companiesIhaveworked where or...select count(*) from companiesIhaveworked where oracle = "2 much $"<BR/><BR/>result - all. ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-36020360021519557682008-12-11T03:02:00.000-05:002008-12-11T03:02:00.000-05:00@mcohen"And as Java has superceded C"By the way, I...@mcohen<BR/><BR/>"And as Java has superceded C"<BR/><BR/>By the way, I think you left your credibility back there...<BR/><BR/>"No, I'm talking about application development."<BR/><BR/>So was I.<BR/><BR/>"Entire applications should not be written in pl-sql. "<BR/><BR/>Why not? You've failed to come up with a compelling argument so far, other than "they shouldn't" or that "PL/SQL doesn't have as good OO capabilities as Java" (my wording not yours). <BR/><BR/>Nobody disagree's with you that Java (and some other languages) has much better OO capabiities. However that's hardly the point is it?<BR/><BR/>If i don't want to develop using an OO methodology (and once again, remember I can do that with Oracle if I wanted to) then PL/SQL is a perfectly suited development tool for many requirements.<BR/><BR/>"Oracle objects aren't really in the same class as OO languages and environments like Java or C#."<BR/><BR/>Nice pun by the way...<BR/><BR/>Oracle Objects have attributes, methods, inheritance, supertypes, subtypes, polymorphism and lots of other features.<BR/><BR/>Which critical features do you believe they're missing that makes them so much less useful than other OO tools have?<BR/><BR/>"it should be avoided for general purpose development."<BR/><BR/>Why? Because you say so? Again, you have failed to come up with a compelling argument why it shouldn't be used. If your entire argument hangs against it not being 'OO enough' then it sounds like you're too wrapped up in the concepts to see the bigger picture.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-89683172948991401232008-12-10T18:44:00.000-05:002008-12-10T18:44:00.000-05:00Let me wrap this up in a bow. If you think there ...Let me wrap this up in a bow. If you think there is, in fact, a "vs." in any portion of either the application code platform or the persistent repository platform in any way - you are tool that every one should ignore.<BR/><BR/>The supposition of the "vs." even existing is based on FUD by those familiar with only a narrow understanding of the many techniques to get the job done.Clever Idea Widgetryhttps://www.blogger.com/profile/11224068405843575576noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-79177544887894429002008-12-10T17:47:00.000-05:002008-12-10T17:47:00.000-05:00Well Chet, i would say that you and your readers h...Well Chet, i would say that you and your readers haven't been able to defend your case very well. (And really, how could you be expected to?) I'm sure it's not a pleasant prospect, but the reality is that the RDBMS is increasingly becoming irrelevant. You and your readers have a large personal investment in the technology, which you stand to lose to the degree it does become relegated to a niche market. But it does you no good to bury your head in the sand and deny the reality. Instead you should embrace the reality of software development today and get on with the task of learning more current technologies.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-76033154204837646072008-12-10T17:35:00.000-05:002008-12-10T17:35:00.000-05:00"But again, I'd disagree...I think all developers ..."But again, I'd disagree...I think all developers should have a good grounding in memory management, it's a fundamental part of knowing how computer systems operate."<BR/><BR/>That's what university is for. I know how registers work, that doesn't mean I should program against them when writing applications. Again, the history of computer programming, in other words the history of higher and higher levels of abstraction, bears this out.<BR/><BR/><BR/>"Surely you're not suggesting that *every* development has to be done using OO techniques? Surely not...you mean that we should be coding using OO techniques whether the situation warrants it or not, just for the sake of using OO?"<BR/><BR/>No, I'm talking about application development. If you've got some batch job that just has to push data around from one table to another, or from one db to another, for whatever reason, then sure, use pl-sql for that. But again, to go back to Chet's original statement, "PL/SQL is a 3GL (or is it 4) and you can write entire applications using it...and if you do that right, an incredibly robust and scalable application at that." Entire applications should not be written in pl-sql. <BR/><BR/><BR/>"Besides..should you want to do that, I refer back to my earlier comment, Oracle PL/SQL has object support built in (for some years as I said), so I can use OO techniques with PL/SQL should I want to (whether I would or not is a different matter)."<BR/><BR/>Oracle or Postrges would be a rather poor choice. Oracle objects aren't really in the same class as OO languages and environments like Java or C#. It's not even really a valid comparison.<BR/><BR/><BR/><BR/>"No, I still fail to be convinced that I shouldn't be using PL/SQL for 'general purpose development' (I think you also worded that incorrectly, surely you mean PL/SQL should be avoided for 'OO development', since I would put 'general purpose development' into the non-OO category). "<BR/><BR/>No, I chose my words carefully. PL-SQL should only really be used for strictly database development, it should be avoided for general purpose development.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-8053911539391237902008-12-10T17:18:00.000-05:002008-12-10T17:18:00.000-05:00"Regardless, this is low-level implementation deta..."Regardless, this is low-level implementation detail that I shouldn't be concerned with, just as manual memory management is a low-level implementation detail that I shouldn't be concerned with."<BR/><BR/>But again, I'd disagree...I think all developers should have a good grounding in memory management, it's a fundamental part of knowing how computer systems operate.<BR/><BR/>" but the fact remains that PL-SQL simply cannot match the power and expressiveness of today's OO languages, and as such, should be avoided for general purpose application development. "<BR/><BR/>Surely you're not suggesting that *every* development has to be done using OO techniques? Surely not...you mean that we should be coding using OO techniques whether the situation warrants it or not, just for the sake of using OO?<BR/><BR/>Besides..should you want to do that, I refer back to my earlier comment, Oracle PL/SQL has object support built in (for some years as I said), so I can use OO techniques with PL/SQL should I want to (whether I would or not is a different matter).<BR/><BR/>So, I still fail to be convinced that I shouldn't be using PL/SQL for 'general purpose development' (I think you also worded that incorrectly, surely you mean PL/SQL should be avoided for 'OO development', since I would put 'general purpose development' into the non-OO category).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-69446004805295534312008-12-10T16:25:00.000-05:002008-12-10T16:25:00.000-05:00"Where did I say that? I said that 'widespread ado..."Where did I say that? I said that 'widespread adoption' is not the same as 'successful adoption'. Just as you're not saying (I hope) that they're all successful, I am saying that they're not all successful."<BR/><BR/>Their success or failure is irrelevant to our discussion. The important point was that ORM's adoption has been widespread. <BR/><BR/><BR/>"PL/SQL not SQL..."<BR/><BR/>Either one.<BR/><BR/><BR/>"We're not confusing it, what we are saying is that when you store your *data* in a *database* it offers many advantages and features over (for example) storing it in an XML file on the filesystem, surely you concede that?"<BR/><BR/>In some cases an rdbms offers advantages, in other cases an xml db, in still yet other cases something like Amazon S3 is the right choice. The cases where rdbms is the right choice are shrinking. Regardless, this is low-level implementation detail that I shouldn't be concerned with, just as manual memory management is a low-level implementation detail that I shouldn't be concerned with. Really, why is this so contraversial for you?<BR/><BR/><BR/>"The difference is, I can write my SQL and PL/SQL inside APEX because I'm comfortable at that level, I know how to code SQL and PL/SQL. The tool works for me (it's not going to work for everyone, just like Java/.NET etc isn't). My point is, with the tool I use, PL/SQL becomes a very real development environment (because under the hood that is what APEX is using)." <BR/><BR/>You may be comfortable using some tool, but the fact remains that PL-SQL simply cannot match the power and expressiveness of today's OO languages, and as such, should be avoided for general purpose application development. This was Chet's original comment that started all this.<BR/><BR/>Chet's comment:<BR/>"It is a great platform if you know how to leverage it. PL/SQL is a 3GL (or is it 4) and you can write entire applications using it...and if you do that right, an incredibly robust and scalable application at that."mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-14863426323702688322008-12-10T16:08:00.000-05:002008-12-10T16:08:00.000-05:00@mcohen"So now you're going to argue that all thes...@mcohen<BR/><BR/>"So now you're going to argue that all these developers using ORMs are failing with them? "<BR/><BR/>Where did I say that? I said that 'widespread adoption' is not the same as 'successful adoption'. <BR/><BR/>Just as you're not saying (I hope) that they're all successful, I am saying that they're not all successful.<BR/><BR/>"We're talking about the suitability of SQL as an application development language, not the possibility."<BR/><BR/>PL/SQL not SQL...<BR/><BR/>"Continually I see you making the mistake of confusing the more general concept of data with a database."<BR/><BR/>We're not confusing it, what we are saying is that when you store your *data* in a *database* it offers many advantages and features over (for example) storing it in an XML file on the filesystem, surely you concede that?<BR/><BR/>"Hand coding SQL statements is quickly becoming a thing of the past. Get used to it."<BR/><BR/>Ummm...you're really mistaking me for someone else I think?<BR/><BR/>My tool of choice for development these days is Oracle Application Express (http://otn.oracle.com/apex). <BR/><BR/>It's a web development tool, runs completely inside the database. Makes a lot of web development tasks extremely simple (such as session handling etc), CRUD applications are a breeze.<BR/><BR/>The difference is, I can write my SQL and PL/SQL inside APEX because I'm comfortable at that level, I know how to code SQL and PL/SQL. The tool works for me (it's not going to work for everyone, just like Java/.NET etc isn't). <BR/><BR/>My point is, with the tool I use, PL/SQL becomes a very real development environment (because under the hood that is what APEX is using).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-87243316335926577862008-12-10T15:48:00.000-05:002008-12-10T15:48:00.000-05:00'Widespread adoption' (whatever % that translates ...'Widespread adoption' (whatever % that translates into) is not necessarily the same thing as 'successful adoption' sadly ;)<BR/><BR/>So now you're going to argue that all these developers using ORMs are failing with them? C'mon dude. Your point's irrelevant anyway. I used the broad adoption of ORM technologies to illustrate the point that developers are unsatisfied with the programming model offered by SQL and would prefer to use OO techniques. <BR/><BR/><BR/>"Reality disagrees with you, there are many applications running out in production with a strong PL/SQL code base."<BR/><BR/>No John, reality doesn't disagree with me. We're talking about the suitability of SQL as an application development language, not the possibility. You can write applications in assembly too, that doesn't mean it's a good idea.<BR/><BR/><BR/>"Depends if you take the very narrow focus view of "All I care about is my code" rather than the "I care about the application as a whole". As a developer I think you should care about aspects of the application that you may not be directly involved with."<BR/><BR/>I should be concerned with implementing business logic. Data persistence is a relatively low level concern that really shouldn't occupy my time.<BR/><BR/><BR/>"Hmm, aren't you conflicting with your prior statement there? On the one hand you're saying you don't want to know about such (DB) details, on the other you're telling *us* to broaden our perspectives...pot...kettle ;)"<BR/><BR/>Is this really the best you can do? I shouldn't be concerned with the details of the persistence mechanism, but I'm fully aware of the available mechanisms. Yes, you db guys need to broaden your perspectives. Continually I see you making the mistake of confusing the more general concept of data with a database. <BR/><BR/><BR/>"If I were to make a comparable argument I'd suggest you database guys don't understand OO."<BR/><BR/>Again...those generalization will really kill your argument for you. <BR/><BR/>That's why I'm not making them John. Reading comprehension. <BR/><BR/><BR/>"Actually, I consider myself a Developer/DBA (or DBA/Developer depending on the day of the week), so I have seen things from both sides of the fence. That's why I like my logic inside the DB, I've seen what putting it outside the DB can do when you change your development tool/infrastructure ;) "<BR/><BR/>Or, applications come and go, the data always remains. But the development platform changes typically as new applications come and go. Implicit in that is new application functionality. The fact of the matter is, there's not much room anymore for application logic implemented within an rdbms. The web dominates today, and special purpose environments like RoR or Grails provide developers with unparalled productivity. CRUD apps go up in minutes. Hand coding SQL statements is quickly becoming a thing of the past. Get used to it.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-24068344264145375252008-12-10T15:18:00.000-05:002008-12-10T15:18:00.000-05:00@mcohen"Even a cursory glance at the landscape rev...@mcohen<BR/><BR/>"Even a cursory glance at the landscape reveals widespread adoption of ORM technologies."<BR/><BR/>'Widespread adoption' (whatever % that translates into) is not necessarily the same thing as 'successful adoption' sadly ;)<BR/><BR/>"This stems from Chet's original comment that "PL-SQL was an excellent choice as an application development language. I'm arguing that it most definitely is not. It's suited for the rather narrow concern data manipulation within an rdbms."<BR/><BR/>Reality disagrees with you, there are many applications running out in production with a strong PL/SQL code base.<BR/><BR/>"If the data were persisted to disk in xml files it should make no difference to me."<BR/><BR/>Depends if you take the very narrow focus view of "All I care about is my code" rather than the "I care about the application as a whole".<BR/><BR/>As a developer I think you should care about aspects of the application that you may not be directly involved with.<BR/><BR/><BR/>"The level of myopia with you database guys is staggering. Expand your horizons. Broaden your perspective. Data and the database are not synonymous."<BR/><BR/>Hmm, aren't you conflicting with your prior statement there? On the one hand you're saying you don't want to know about such (DB) details, on the other you're telling *us* to broaden our perspectives...pot...kettle ;)<BR/><BR/>"If I were to make a comparable argument I'd suggest you database guys don't understand OO."<BR/><BR/>Again...those generalization will really kill your argument for you. FYI one of my favourite development tools (outside of Oracle) that I've used is Delphi, which I used for many years and I'm certainly more than familiar with OO development.<BR/><BR/>Actually, I consider myself a Developer/DBA (or DBA/Developer depending on the day of the week), so I have seen things from both sides of the fence. That's why I like my logic inside the DB, I've seen what putting it outside the DB can do when you change your development tool/infrastructure ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-87678464207902836702008-12-10T13:48:00.000-05:002008-12-10T13:48:00.000-05:00"What is the trend? That people want it?"No, the t..."What is the trend? That people want it?"<BR/><BR/>No, the trend is increasing levels of abstraction. This is simply the history of computer programming. <BR/><BR/><BR/>"Don't forget, your perception of how much ORM is used is based on your own experience (I'm guessing it's the area you work in on a day to day basis)."<BR/><BR/>I work with ORM tools probably on a daily basis. My perception isn't based on my personal experience. Even a cursory glance at the landscape reveals widespread adoption of ORM technologies.<BR/>http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software<BR/><BR/><BR/>"There are lots of folks/companies/languages out there that don't use/require/enforce ORM to be useful."<BR/><BR/>And nowhere did I claim such a thing. <BR/><BR/><BR/>"Neither is inherently 'better' than the other, it depends very much on the context of what you're trying to achieve."<BR/><BR/>This stems from Chet's original comment that "PL-SQL was an excellent choice as an application development language." I'm arguing that it most definitely is not. It's suited for the rather narrow concern data manipulation within an rdbms.<BR/><BR/><BR/>"They can also be (ab)used to *create* additional complexity. So care is required not to over-engineer the solution."<BR/><BR/>Yes, anything can be misused or abused. What's the point? On balance, OO has been a boon for developers. I don't think that's a controversial statement.<BR/><BR/><BR/>"Should I, as a developer, know how the Employee table relates to the Department table and the Salarys table? Almost certainly yes (assuming that's the data I'm working with). Without knowing how my data is organized within the database, how can I possibly make best use of that data when it comes to processing it?"<BR/><BR/>No, you're concerned with how an Employee relates to a Department and to a Salary. These are business concepts, which quite often have rich functionality and interactions among them that must be expressed in the application. The last 20 years of software development has proven that these relationships and behavior are best modeled using OO techniques. The fact there are tables involved in an rdbms should only be an incidental implementation detail. If the data were persisted to disk in xml files it should make no difference to me. The level of myopia with you database guys is staggering. Expand your horizons. Broaden your perspective. Data and the database are not synonymous.<BR/><BR/><BR/>"If we take this to the natural conclusion, you are essentially saying that given 2 developers -<BR/><BR/>1) Developer X who understands the development tool.<BR/>2) Developer Y who understands the development tool AND the database (including the data).<BR/><BR/>You are saying that Developer X has the 'edge'?"<BR/><BR/>Nice straw man. Of cours I'm not saying that. It's not an argument to simply say I don't understand the database. If I were to make a comparable argument I'd suggest you database guys don't understand OO. But I'm not suggesting that. I'm giving you the benefit of the doubt. I would expect to be afforded the same courtesy. Most devs I've come across who share my views that SQL is poorly suited for expressing application logic and look to ORMs to bridge the gap between the relational and object worlds have excellent knowledge of database technology.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-945246521622774222008-12-10T13:26:00.000-05:002008-12-10T13:26:00.000-05:00I'm not nearly as versed in DB matters as most of ...I'm not nearly as versed in DB matters as most of you, and I'm not a biochemist, but let me say what I believe: Nothing lives without heat. If this is true, I would say it applies to ideas as well. So with that, let me say "thanks" to Mr. M for being the OHS (official heat source) on this post. Keep the language hot, that's what I say; it keeps the subject alive. Just guard yourself and don't take any of it personally (as I can see Chet has mastered).<BR/>(So philosophy and general theory is my thing you see.)<BR/>Now I stumble into the database arena. (Disclaimer: This could be ugly.)<BR/>What the fuck, Chet?!! jkjk...that was me imitating Mr. M. (Maybe I can be the OHS some day.)<BR/>Another theory: chaos rules. If you like the database-less database, make it work. Promote it. Perfect it. Database-centric type? Same thing. They both work.<BR/>What will rule depends not so much on what's *best* as it does which side works harder to make their side supreme.<BR/>What demands does the future hold for the use of data and what will the application software trends be? Anyone? Nostradamus here today? Yeah, nobody knows though many of you know in what direction things appear to be heading at the moment.<BR/>Here's what we do know: They both work exceptionally well when the people using them know what the f**ck they're doing (nod to Mr. M).<BR/>Let's admit: When you're up against Oracle, you're facing a worthy opponent and it really doesn't matter what the "facts" of the matter are.<BR/>Want to unseat the giant? (We all love to see a giant fall.)<BR/>For me, for now, I'll continue trying to master the ways of the giant so when I expose its weaknesses I'll know what the f**ck I'm talking about (Mr. M).Unknownhttps://www.blogger.com/profile/14401032504437933147noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-79136912500324655912008-12-10T12:44:00.000-05:002008-12-10T12:44:00.000-05:00@mcohen"So I could swap out a SQL provider for an ...@mcohen<BR/><BR/>"So I could swap out a SQL provider for an XML db provider or an Amazon S3 provider. We're not there yet, but this is the trend."<BR/><BR/>What is the trend? That people want it? Sure...people always want things that sound cool. Does everyone *need* that level of abstraction? Almost certainly not.<BR/><BR/>You're talking about a small *niche* area of applications there, the ones were it makes sense to switch out a SQL Provider to an XML Provider etc.<BR/><BR/>"the adoption of ORM technologies, pretty much across the language spectrum"<BR/><BR/>Don't forget, your perception of how much ORM is used is based on your own experience (I'm guessing it's the area you work in on a day to day basis). There are lots of folks/companies/languages out there that don't use/require/enforce ORM to be useful.<BR/><BR/>"but SQL just can't compare to the power and expressiveness of modern programming languages."<BR/><BR/>Horses for courses as we say over here in the UK. Nobody is pretending that developing a program using PL/SQL is the same as using C (for example). Neither is inherently 'better' than the other, it depends very much on the context of what you're trying to achieve.<BR/><BR/>"Further, OO techniques have proven to be quite useful at managing complexity within application code"<BR/><BR/>Sure, I agree, they can. They can also be (ab)used to *create* additional complexity. So care is required not to over-engineer the solution.<BR/><BR/>By the way, you know that Oracle supports Object types in the database right (and has done for some time - they may not be perfect yet but they're there)? <BR/><BR/>"It's a low-level concern that developers shouldn't have to deal with"<BR/><BR/>It depends what level you're talking about.<BR/><BR/>Should I, as a developer, care which sector of the disk my data is stored on? Nope, probably almost certainly not.<BR/><BR/>Should I, as a developer, know how the Employee table relates to the Department table and the Salarys table? Almost certainly yes (assuming that's the data I'm working with).<BR/><BR/>Without knowing how my data is organized within the database, how can I possibly make best use of that data when it comes to processing it?<BR/><BR/>If we take this to the natural conclusion, you are essentially saying that given 2 developers -<BR/><BR/>1) Developer X who understands the development tool.<BR/>2) Developer Y who understands the development tool AND the database (including the data).<BR/><BR/>You are saying that Developer X has the 'edge'? I couldn't disagree with that more.<BR/><BR/>JohnAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-76378820377368039512008-12-10T11:34:00.000-05:002008-12-10T11:34:00.000-05:00@John Scott"It has been possible to do that for a ...@John Scott<BR/><BR/>"It has been possible to do that for a very long time"<BR/><BR/>What I'm talking about here is what the JPA folks sometimes offered as their goal - generic, pluggable persistence. So I could swap out a SQL provider for an XML db provider or an Amazon S3 provider. We're not there yet, but this is the trend.<BR/><BR/>"You mean unsuited to the way you want to use it? Don't generalize that *everyone* wants to abstract in this way, because not everyone does."<BR/><BR/>Well John, the adoption of ORM technologies, pretty much across the language spectrum, suggests that I'm far from the only one who finds an SQL programming model lacking. And there is good reason for this. The relational model is excellent for data storage, and SQL is very good at set-based data retrieval and manipulation, but SQL just can't compare to the power and expressiveness of modern programming languages. Further, OO techniques have proven to be quite useful at managing complexity within application code, but the disconnect between the object world and the relational world is so strong that tremendous effort has been devoted toward relieving developers of the onerous task of transitioning between the two worlds, with commensurate gains in developer productivity.<BR/><BR/>"Perhaps the reason you're finding it unsuited is because you're trying to fight against it rather than working with it?"<BR/><BR/>It's not a question of fighting with it or working with it. The point is that you shouldn't even have to work with it. It's a low-level concern that developers shouldn't have to deal with. I have this bit of data and I want to save it, and later on at some point in the future I want to work with it again. That should be the extent of my concern. It's analagous to manual memory management. I just want to create an object, I shouldn't have to be concerned with the details of allocating memory in order to do that. And as Java has superceded C, soon enough the low-level programming model of the rdbms will be superceded.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-17614197881514663682008-12-10T11:09:00.000-05:002008-12-10T11:09:00.000-05:00@mcohen"Soon it will be possible to abstract away ...@mcohen<BR/><BR/>"Soon it will be possible to abstract away from the developer the very fact that we're using an rdbms at all for persistence. This is a Good Thing."<BR/><BR/>It has been possible to do that for a very long time (through the use of library functions, API's etc). I worked on a project nearly 20 years ago where the developers didn't have direct access to the DB we just used common API routines which handled it all for us.<BR/><BR/>I am not against frameworks/persistence layers etc per-se, *as long* as they are well written and understand the strengths and weaknesses of the underlying database. It is when these tools try to be too generic and fail to take into account the subtle ways that different vendors databases can work when chaos reigns.<BR/><BR/><BR/>"what we're talking about here is simply the specific mechanism of data storage, one that is rather long in the tooth, and showing it's age, and is quickly becoming unsuited for modern software development given current trends."<BR/><BR/>You mean unsuited to the way you want to use it? Don't generalize that *everyone* wants to abstract in this way, because not everyone does.<BR/><BR/>Perhaps the reason you're finding it unsuited is because you're trying to fight against it rather than working with it?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-62049099061055138462008-12-10T10:52:00.000-05:002008-12-10T10:52:00.000-05:00@John ScottAgreed. True database independence is r...@John Scott<BR/><BR/>Agreed. True database independence is rarely achieved, and the actual requirement for it is probably even rarer. I was just using this as an example of abstraction away from the database. So it's possible right now to abstract away the specific details of the database we're using. Soon it will be possible to abstract away from the developer the very fact that we're using an rdbms at all for persistence. This is a Good Thing. And a natural progression in the kinds of abstractions that we work with every day as developers. <BR/><BR/>@Narenda<BR/><BR/>"And if I remember correctly, few years ago(around Y2K), there was a belief JAVA and Object-Oriented Programming will outsmart all other technologies (including databases) and make everything obsolete."<BR/><BR/>I'm not sure if anyone expected a general purpose language like Java to replace rdbms's. I certainly don't know of anyone who was espousing such an opinion. It is hard however to overstate the dominance Java has achieved in about a dozen short years. Especially when you consider the very strong desire of Microsoft to bring forward in the marketplace opposition. Considering Microsoft's considerable clout in the industry and with developers, .NET has largely been a failure.<BR/><BR/>"So JAVA/OO is the way forward..."<BR/><BR/>Well, Java really has been a way forward in that it's become the defacto standard for your average corporate developer to work with an OO language while enjoying the productivity boon provided by automatic memory management all provided on a robust scalable platform. As they say, Java is the COBOL of the 21st century.<BR/><BR/>"Well, we are in 2008 & we still have databases (Oracle, SQL Server, Sybase etc.) and all large/medum/small organisations use it extensively."<BR/><BR/>This is true. But the writing is on the wall. Datagrid products like Tangosol Coherence are still somewhat new, but very soon that space too will become commoditized. And it's not just Wall Street trading applications that can realize large benefits from these datagrids. Plus, as I said before, the accelerating trend is toward distributed datasources located elsewhere on the network (e.g. the web). The importance and primacy of position of the rdbms in the enterprise is clearly waning. Quite soon I imagine these dinosaurs will occupy only a small, niche space in organizations.<BR/><BR/>"As the famous Tom Kyte says...'Applications come and go, data remains"'"<BR/><BR/>This is largely correct. But don't confuse databases with "data." They are most certainly not the same. Remember, what we're talking about here is simply the specific mechanism of data storage, one that is rather long in the tooth, and showing it's age, and is quickly becoming unsuited for modern software development given current trends.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-29689902899593595572008-12-10T09:57:00.000-05:002008-12-10T09:57:00.000-05:00@mcohen01>I could swap Oracle out for Sybase &g...@mcohen01<BR/><BR/>>I could swap Oracle out for Sybase >with a configuration parameter.<BR/><BR/>Good luck with that. <BR/><BR/>I've seen plenty of projects that have 'database independence', very few of them (none maybe?) have ever successfully switched out one DB for another just with a 'configuration parameter'. It's a nice ideal...rarely holds up in practice though.<BR/><BR/>Whether you use Oracle, Sybase, MySQL etc you *should* be using all the features you have "paid for" (where paid for means in terms of money or time investment), rather than aiming for the lowest common denominator of functionality. <BR/><BR/>John.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-4938219490210263172008-12-10T06:27:00.000-05:002008-12-10T06:27:00.000-05:00And if I remember correctly, few years ago(around ...And if I remember correctly, few years ago(around Y2K), there was a belief JAVA and Object-Oriented Programming will outsmart all other technologies (including databases) and make everything obsolete. So JAVA/OO is the way forward...<BR/>Well, we are in 2008 & we still have databases (Oracle, SQL Server, Sybase etc.) and all large/medum/small organisations use it extensively.<BR/>As the famous Tom Kyte says..."Applications come and go, data remains"<BR/>Let us see 5/10 years from now, how many businesses "believe" in this "database-are-data dumps" approach.Narendrahttps://www.blogger.com/profile/14645699853364658640noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-20575278779100774302008-12-10T05:11:00.000-05:002008-12-10T05:11:00.000-05:00@Noons"Persisting something to a database is reall...@Noons<BR/><BR/>"Persisting something to a database is really a low-level concern that as an application developer I shouldn't even have to be bothered with"<BR/><BR/>What exactly do you think is "idiotic and ignorant" about this statement? As an application developer, when I write something to the database all I really care about is that this particular bit of data is kept around somewhere so that I can look at and do something with it later on down the road, even if I turn off the power on the computer. But I'm not especially concerned with the fact that the means of achieving this goal is via a relational database. In fact, to be quite clear about it, I don't give a sh_t at all that we're using a relational database. It's an implementation detail that in a perfect world I really shouldn't be concerned with. So for example, it shouldn't really matter to me that we're using an Oracle database over say, an object database or xml files, or Amazon S3. We're not quite there yet, but we're making progress. You can examples of this in ORM technology. So instead of writing "insert into...." I just call save() on an object. If I want the data back again I just call get(id) and I pass in some identifier. This happens to be a primary key but it could be any identifier really. Already if I'm using an ORM the actual brand of database I'm using is transparent to me. I could swap Oracle out for Sybase with a configuration parameter. <BR/><BR/>See, the real problem here, and again, on a site like oraclenerd.com, it's clear this is not a popular opinion, but the real problem here is that all you guys like Chet make your bread and butter programming Oracle databases. If Oracle's not on top, and especially if rdbms's lose the stature they've traditionally held within the enterprise, this totally threatens your livelihood because of how personally invested you are in the technology. That's why Chet, and I suspect most folks here, are totally standoffish if not outright opposed to things like MySQL or datagrid-type products like Coherence.<BR/><BR/>The real problem here is that you db guys basically have a lower level view than that of an application developer. As an app dev you're concerned with the entire application, and as such you're constantly working at the database layer as well as the application layer. So you have this holistic view of things. Whereas dba's have a much more narrow view of things. So if we extrapolate current trends outward, "the network is the computer," we can see a world where applications use multiple distributed heterogenous datasources located in the web ether, the cloud to use current fashionable terms, and quite possibly require no actual local disk-based persistence, but in the rare event that such persistence is required it's achieved with the lingua franca of the web, XML, and there simply is no longer a compelling reason to use expensive legacy decaying dinosaurs like an Oracle rdbms. You should take a page from the Agilists and instead of resisting change embrace it, for this is future of things.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-65229207066654291022008-12-10T00:42:00.000-05:002008-12-10T00:42:00.000-05:00"Persisting something to a database is really a lo..."Persisting something to a database is really a low-level concern that as an application developer I shouldn't even have to be bothered with"<BR/><BR/><BR/>Yikes! I thought I had heard all possible variations of idiocy and sheer unadulterated ignorance, but it looks like the oop/java brigade continues to excel at it...Noonshttps://www.blogger.com/profile/07694829378563989648noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-47808008691659005792008-12-09T23:00:00.000-05:002008-12-09T23:00:00.000-05:00@crisatunityHe does do that doesn't he? I always ...@crisatunity<BR/><BR/>He does do that doesn't he? I always forget he's just trying to rile me up.<BR/><BR/>The first time it happened I was mad...now I just laugh. I know he doesn't truly believe it to that extreme (at least I think).<BR/><BR/>He's well known for his antics...oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-41185066636727219112008-12-09T22:52:00.000-05:002008-12-09T22:52:00.000-05:00Chet, of course you are more correct more reasoned...Chet, of course you are more correct more reasoned and better equipped to carry your points to light, but you are a fool to take the bait on this boring tired old fight with a tool that gets off on razzing you.Clever Idea Widgetryhttps://www.blogger.com/profile/11224068405843575576noreply@blogger.com