tag:blogger.com,1999:blog-8884584404576003487.post325612574443515851..comments2024-02-29T09:43:12.251-05:00Comments on ORACLENERD: Classic: Application Developers vs. Database Developersoraclenerdhttp://www.blogger.com/profile/12412013306950057961noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-8884584404576003487.post-66205144003215786712009-07-08T11:31:42.186-04:002009-07-08T11:31:42.186-04:00Information without context is in fact meaningless...Information without context is in fact meaningless. Here's an example: "yellow".<br /><br />The architectural pattern which provides the context is irrelevant. If you want to argue with that go right ahead.jblhttps://www.blogger.com/profile/14419489941346549022noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-47340639162189117792009-07-08T00:52:41.768-04:002009-07-08T00:52:41.768-04:00"that data only becomes "valuable" ..."that data only becomes "valuable" or meaningful because of the context in which it has been presented by the application. the application dictates whether data is valuable or not. data itself is rarely intrinsically valuable."<br /><br /><br />That's a good one. Care to pass that by the finance folks charged with allocating budgets to insane "developers"?<br /><br />It would last just about 5 seconds: as long as it takes to read that pile of crap.<br /><br />Once again, the totaly irresponsible nature of so-called "developers' shines through. <br /><br />These people are nothing more than expensive quacks who need to be eradicated from IT.<br /><br />I'll tell you who is going to be out of a job in 10 years: all these twitter idiots. Without excepion.Noonshttps://www.blogger.com/profile/07694829378563989648noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-44768171449657685012009-07-07T21:34:54.424-04:002009-07-07T21:34:54.424-04:00Look at the human body. Muscles and a skeleton are...Look at the human body. Muscles and a skeleton are both essential, working together. The skeleton is a bit more persistent, but it becomes pretty unimportant once the muscles stop moving it around. <br />There are animals that move around without a skeleton. There are apps that work without data persistance (mostly realtime stuff). There are apps that persist data other than in an RDBMS.<br /><br />Equally there's bucket loads of data without a specific application. That's what Excel is all about, a generic app to handle a variety of data. And thats what a database is, the first layer of a generic data handling app. [Though the storage admins may say that RAID is the first layer.]<br /><br />In computing, we can guarantee everything will change. But enterprises will have data they want preserved. They'll have someone who's job it is to do that, just as they have systems and storage administrators today. [Okay, maybe it will be outsourced to the cloud.]<br /><br />But for the apps side, they'll probably be buying that from Oracle and SAP and doing very little of their own development. So for job security, you're best off sticking with the data.SydOraclehttps://www.blogger.com/profile/08828771074492585943noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-64873713692226208682009-07-07T21:13:28.102-04:002009-07-07T21:13:28.102-04:00@mcohen01
re: how did i get started
I didn'...@mcohen01<br /><br />re: how did i get started<br /><br />I didn't have as grand plans as you. I started as a secretary essentially, doing data entry for some 1000 odd letters we sent out each month.<br /><br />Hmmm...how can I do this better/faster/easier?<br /><br />Access. (yikes)<br /><br />And so it began. I was fortunate enough to get a job (from a friend) in an Oracle shop...and the rest is history.<br /><br />re: anathema<br /><br />I would disagree, mostly. I'm not married to Oracle. I've earned a pretty darn good living off of it. I could and will adapt. Your view of DBAs as the stodgy old coots might not be too far off...but they have also been at the center of everything (enterpise speaking) for the longest time. They've had to go in an fix problems...clean data...merge data...all kinds of craziness. Sometimes created by App Dev people, sometimes created by DB Dev people. They are responsible for maintaining the system thus are the ones who get yelled at or blamed most often.<br /><br />I'll say it again though, for 99.9% of the apps out there, a database (Oracle) will do just fine. PL/SQL (4GL) is <i>very</i> robust. Application Express makes creating the presentation layer ever so easy.<br /><br />Does that mean I don't want to see what the new stuff is all about? Absolutely not. But data <i>is</i> very important to a business. They need to know the address of the customer who just purchased a widget. They need to know how much money was spent in the last month on Widget 1, 2 and 3. The data is critical to the business. And I'm pretty sure you can ask many DBAs or Database types how they ran their first reports and they'll tell you SQL*Plus (the first application to access the data).oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-61928467815775101922009-07-07T14:35:12.779-04:002009-07-07T14:35:12.779-04:00"it's the application, stupid!"
how..."it's the application, stupid!"<br /><br />how do you not see this?<br /><br />dude, how did you get started in this field? maybe you typed in lines of BASIC to make a turtle move across the screen? me, i wanted to make tutorials for students to work through, Computer Assisted Instruction, as it's known. in other words, i wanted to do something on the screen. i needed to implement some bit of functionality. it didn't really matter to me whether the tutorial data and student responses were stored in a relational database, in xml, in text files, wherever. it didn't matter. sure, a relational model makes things easier, but really dude, i would have preferred to just be able to tag/annotate something as being "persistent." i would have rather just been able to say, "save this bit of data here, i don't care how you do it, just save it, so i can look it up later possibly." persistence is well on the way to being a meta concern in application programming. you database guys are so caught up in the minutiae, the low level plumbing, of this one small aspect of application development, i can only chalk it up to the fact that you're so heavily invested personally in the technology that anything that threatens it is by definition anathema to you. there's a simple solution to your problem though....mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-86350952248848694942009-07-07T14:24:21.141-04:002009-07-07T14:24:21.141-04:00"Back to my argument, which hasn't been e..."Back to my argument, which hasn't been explicitly stated, is data in the enterprise."<br /><br />the problem here chet is that when you say "data" what you really mean is "the database," and more specifically, "the oracle database." and both of those are waning in their influence. think about it, if i've got a WAN and a data grid in my enterprise, what do i even need a database for? serialize it all to disk once a day if you really can't sleep at night. <br /><br />dude, databases are quickly becoming dinosaur technology. sorry, i know you don't want to hear that, but that's the case. invest in yourself, learn new things, and then you won't have all your eggs in larry's basket.<br /><br /><br />"In the enterprise the application comes and goes (it started with SQL*Plus, to EJB, to .NET now on to RoR)."<br /><br />and this should tell you something. the business value is realized not from the data sitting there in whatever medium or format or whatever storage device, the business value is realized by applications that do something for the business.<br /><br />"it's the application, stupid!"<br /><br />how do you not see this?<br /><br /><br />"Where would you rather spend your time? The data just needs to be "skinned," the app becomes the presentation of it...nothing more."<br /><br />skinned? nothing more? but dude, this "skinning" as you call it, this is everything. the business doesn't give a sh_t about data, it cares about application functionality. <br /><br />let's try this another way.....if we fire all the dbas tomorrow, can the app devs muddle through the database stuff, or find some other way of persisting the data, say, in xml files? if we fire all the app devs tomorrow, can the dbas build the app?mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-54900277843939927112009-07-07T14:05:20.756-04:002009-07-07T14:05:20.756-04:00@chet "Where would you rather spend your time...@chet "Where would you rather spend your time?"<br />That generally depends on your job title. ;-)<br /><br />"...the app becomes the presentation of it...nothing more."<br />I'd like to add: "..is one way of doing it."<br /><br />Your ideal job title should be "Systems Architect" Chet! :-Djblhttps://www.blogger.com/profile/14419489941346549022noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-64077321127066271382009-07-07T13:56:00.379-04:002009-07-07T13:56:00.379-04:00@mcohen01
Twitter is a great example for your arg...@mcohen01<br /><br />Twitter is a great example for your argument. The data is relatively unimportant...for the time being. The data mining possibilities of all the unstructured data though.<br /><br />Back to my argument, which hasn't been explicitly stated, is data in the <i>enterprise</i>. In the enterprise the application comes and goes (it started with SQL*Plus, to EJB, to .NET now on to RoR). Where would you rather spend your time? The data just needs to be "skinned," the app becomes the presentation of it...nothing more.oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-12237476708538220662009-07-07T13:52:54.218-04:002009-07-07T13:52:54.218-04:00I generally agree with mcohen01, data qua data is ...I generally agree with mcohen01, data qua data is not meaningful. Perhaps database developers would do well in taking a course on Information Theory?jblhttps://www.blogger.com/profile/14419489941346549022noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-20490292288176480142009-07-07T13:51:33.692-04:002009-07-07T13:51:33.692-04:00@jbl
you know I won't argue math with you.@jbl<br /><br />you know I won't argue math with you.oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-76712385064832464412009-07-07T13:18:33.808-04:002009-07-07T13:18:33.808-04:00"i would still argue that the data is the mos..."i would still argue that the data is the most important thing and it needs to be reasonably structured."<br /><br />and you would be wrong. sorry, no offense, but this perspective of data holding primacy of position is simply wrong. i'll try to give you an example that maybe will illustrate for you why it's a mistake to place so much focus on data (and, with you guys, by extension, databases). <br /><br />twitter might be the best example. the data is worthless. who gives a sh_t if i'm loving my morning cocoa puffs? or whatever the f_ck people "tweet" about....<br /><br />"it's the application, stupid!"<br /><br />that data only becomes "valuable" or meaningful because of the context in which it has been presented by the application. the application dictates whether data is valuable or not. data itself is rarely intrinsically valuable.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-31189374760147721982009-07-07T12:57:50.935-04:002009-07-07T12:57:50.935-04:00...and don't even get me started on closure, c......and don't even get me started on closure, cardinality, and relation calculus! ;-)jblhttps://www.blogger.com/profile/14419489941346549022noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-47550600986275281732009-07-07T12:07:28.436-04:002009-07-07T12:07:28.436-04:00@mcohen01
perhaps you are right in that many data...@mcohen01<br /><br />perhaps you are right in that many database developers have a limited perspective.<br /><br />i would still argue that the data is the most important thing and it needs to be reasonably structured. <br /><br />i won't disagree with the need in certain situations (you mentioned financial services) to do things differently, but there is a price to pay for that which is often not discussed.oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-32650023124230766222009-07-07T01:47:08.158-04:002009-07-07T01:47:08.158-04:00Again, the problem I have with database folks is t...Again, the problem I have with database folks is that many of them have a limited perspective. They don't really have a view of the entire application, only one particular aspect of it, namely, persistence. And really, when you think about it, this is a concern that really should simply be abstracted away from the developer. Meaning, the fact that a given bit of data in my application needs to live beyond the browser closing or the server rebooting, really is a case for metaprogramming. It should be declarative. I should simply be able to flag something as being persistent, and not have to think about it any further. In the Java world we're not quite there, but we're getting closer. <br /><br />Databases are on the way out. About another 10 years and they'll be thought of much as mainframes have been the last few years.mcohen01https://www.blogger.com/profile/10754310184888464447noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-82307935557332211912009-07-07T01:22:04.907-04:002009-07-07T01:22:04.907-04:00@noons
I definitely can't speak to the histor...@noons<br /><br />I definitely can't speak to the history of the RDBMS, but I can't argue much with your argument.<br /><br />I still have a problem, conceptually, of how to use, let alone integrate all of these different solutions. I even read somewhere recently of a NoSQL conference.<br /><br />I do believe that there is a fundamental lack of knowledge on how to properly use a database. Even database developers I've worked with don't seem to know how to properly use them. So it seems natural that the programmer types would gravitate towards something "easier."<br /><br />The object model? It's still relational isn't it? One record (parent) to many (children). I see that it gets flattened in a returned query, i.e. NAME = Chet Justice would be repeated 1 or more times...nevermind...I think it's too late for me to be thinking about this stuff.<br /><br />I need to hang out with more people like you so I don't get all worried about my future. ;)<br /><br />chetoraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-78902480037775472352009-07-07T00:03:53.341-04:002009-07-07T00:03:53.341-04:00One of these days someone will have to explain to ...One of these days someone will have to explain to all these "programmers" that<br /><br />PROGRAMMER != DESIGNER<br /><br />and that without correct data design NO data store whatsoever will be stable, scalable, yaddayadda.<br /><br />Until then, we'll just have to yawn at the ignorance demonstrated by these self-appointed experts...<br /><br />Back in the 70s when databases started to be used the "for" argument was precisely to stop the proliferation of ad-hoc development on flat files. <br /><br />Whereby every programmer out there decreed how to store data and someone else was left with the horrendous task of making it all integrate into a coherent and valid whole that could accurately represent the real enterprise data situation.<br /><br />We are now at the same juncture. <br /><br />These idiots have been left running the show by even more incompetent managers, and now someone will have to figure out how to integrate all these ad-hoc, out of control data stores.<br /><br />Nothing like letting them create the market!Noonshttps://www.blogger.com/profile/07694829378563989648noreply@blogger.com