I used to make this argument myself, by I no longer find it persuasive for guns.
There are quite a number of things we regulate because they have the potential to be dangerous. Cars are a great example. Their primary purpose is to get people places, but we place a lot of restrictions on who can have a car, how much training they need, and what kind of car they can have. Explosives are another example; you wanna do pyrotechnics, you have to get a license.
Guns, especially the guns people are interested in regulating, have a primary purpose of killing people. I agree they should be legal, but I think they should be regulated much more heavily than cars.
For example, Switzerland has a high incidence of gun ownership but low incidence of gun violence; people say that's because there everybody serves time in the military. I also note that people are wealthier and saner there. So maybe for gun ownership we should require a minimum of a 12-week boot-camp-style training on proper gun use, plus yearly 1-week refreshers.
The serious gun owners I know also keep their weapons unloaded and locked up when not in use. So perhaps we could add mandatory secure, theft-proof storage for guns, with random checks. And for any gun owner whose gun ends up killing someone, suicide, homicide or accident, there's minimum 2-year sentence for negligence.
I agree that the problem is mainly stupid or crazy people with guns. But if smart, sane people want to keep their guns, they'll have to find a way to make sure that the stupid and the crazy don't get guns.
Yeah, years of reading the excellent and very numerate general newsweekly The Economist have pretty much spoiled other media for me.
One big one that makes me crazy is use of percentage measures. E.g., a reporter will say that this year 10% of kids failed some test, and that this is up 3% from last year. So what was last year's value, 9.7% (a 3% difference) or 7% (a 3 percentage point difference, but a 43% increase)? Often, they say the former but mean the latter.
Another is the giving of numbers without context. For example, somebody will claim that a city's legal system is racially biased because X% of the people incarcerated are black. They might be right, but their number doesn't help me at all unless I also know what percentage of the city's population are black. And I've frequently heard about the shocking size of California's budget defecit of N billion dollars, but it's the rare article that tells me how big the whole budget is, or how big tax revenues are, or any number that might let me see how big the problem really is.
My interpretation of this: most journalists don't do math unless forced, so they never notice that it's impossible to do math with the numbers they give out.
One trading company I worked for would order a few cases of beer and other drinks in every Friday afternoon. Nobody had to participate, but even the non-drinkers would usually stop work and hang out with the rest.
It was great. It got people talking in a way that wouldn't have happened during the work day. Not only did it make people feel generally closer to their colleagues, but the cross-polination meant a lot of great ideas came up that never would have happened otherwise.
heh. work hasn't been fun in a while. chances are pretty slim i could get these corporate to spring for this type of system - it may motivate people, and we wouldn't want that.
Just buy it. Somebody on Slashdot taught me this great trick: just pretend that 1% of your salary is a bonus from the company to take care of little things that their budgeting process is too clumsy and stupid to deal with.
Yes, especially that last part. A lot of developers talk about reusability, when what they're really doing is gold-plating, adding unused library features.
Is documented (Javadoc stylee, for preference!)
Maybe. I used to write a lot of documentation, but since I've started doing test-first development, I don't really much of it anymore. Why? Because A) I have a good suite of unit tests that document the functionality in a way that can be automatically verified, and B) doing good unit tests encourages you to break things down into small, testable chunks, which are easier to understand.
I know some programmers who have a decent amount of technical ability, but write such convoluted code that it's useless to others. This is worthless to me. They may as well not have coded anything, since it typically takes more time to figure out what's going on than it would to re-write from scratch. I don't consider such a person a good programmer, and I wouldn't hire any of them.
Agreed. For a personal project, that's fine. But in a business, you're hopefully creating code that will last a long time, longer than any single person would want to be responsible for maintaining it.
The reality is that people go on vacation, change projects, they leave jobs, they change careers, and they even die from time to time. If a body of code is so idiosyncratic that only the original programmer can deal with it, then that code will have to be thrown out sooner or later. Why would a business want to invest in a chunk of code when its lifespan will only be as long as one guy stays around?
As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
First off, schema changes are pretty rare once you have production data. Sometimes you add fields and tables, but almost never do you refactor the data model because either you can map your existing data, which proves you haven't achieved any benefit, or you can't which proves you've achieve negative benefit.
For you, perhaps. In my experience, schema changes happen fairly frequently as we add new features or refactor the code base so that it more clearly expresses our understanding of the system.
I think the reason most people don't change their schemas is because they're hard to change. Once I did the work to made them easy to change, I was surprised how often we changed them.
As for programming java-to-COM using a socket, I've actually done that, but trying to get another organization to write their side of such an interface is usually a blank-stare generator. They would probably think for a while and suggest using ODBC instead.
There's nothing wrong with doing that, then. If the protocol they want ends up looking a lot like SQL queries or SQL stored procedure calls, then that's a fine way to write a protocol. Or you can point them at one of the pre-built toolkits for web service APIs; that may be enough of a starter that they think it's just as easy as doing SQL.
Good developers like exploring new technologies and trying new things out. That's how they stay good developers. Smart companies allow for this. Some places, like Google, have formal policies saying that it's ok to spend a certain percentage of your time on personal projects. At others, it's an informal thing.
The alternatives are to a) make your developers miserable, driving away the good, creative ones, or b) make them sneaky. Neither is such a good thing.
It works for me. My bug rates in production are below one per developer-month, and have been for a few years now. How about you?
There are other programming languages than Java in life.
Yes! I've used many of them in the 20 years I've been writing code. I'm not saying that good OO code is the only way to program; I'm just saying that it is one way that has worked for me, and sharing some tips on the right way to do it. What are you so defensive about?
What you are describing is a fine way to lock 1u3ers into using a single platform.
And which platform would that be? There are at least three independent Java JVMs, all implemented from a published spec, running on at least five different processors under at least four different operating systems, some of which are available from dozens of vendors.
Using Java could mean you're locked into the Java language. But really, it doesn't even mean that. If you want a public API to your app you're going to have to write one. Whether that's SQL stored procedures or Java-backed SOAP or any one of a dozen other reasonable choices is a local decision; there is no universal answer.
You wouldn't negligently build an app with a single point of failure. Why would you build a team that way?
Because you work in a shop with only, say, three programmers? [...] It's obvious that the original poster expected to have only one SQL programmer on staff suggesting that it's not an unusual situation.
Doing team-oriented stuff in a small shop is much easier that trying to do it on a large scale. If you only have three developers, there might be only one SQL expert, but that doesn't mean that there has to be only one person writing SQL code. At worst, it means that the SQL expert should pair with (or, less effectively, review the work of) developers doing the SQL work.
Extreme Programing isn't always an economically practical option.
I think that's true, but relatively rare. The productivity, reliability, and business agility gains are substantial. It's my experience that you get more features delivered for the money using agile methods than traditional ones.
You're right, that's why JVMs don't have garbage collection or strong typing, because JVMs are written in C, and C doesn't. Oh, wait. It looks like software can have features that its host language doesn't. How 'bout that?
That's an interesting point, but a) it's one I agree with, and b) it's nothing to do with my point. I was answering NineNine's claim about about granularity of control. In Java, you can have garbage collection precisely because you give up control over memory allocation and deallocation. I think that's a worthwhile tradeoff most of the time.
An SQL database gives some very cool features, like the ability for non-experts to sit down and hack out queries to do ad-hoc reporting. But you give up a lot of granularity of control to get that. Various proprietary vendor extensions let you claw some of that control back, but I don't know of any that let you get all of it back in the same way that Java's JNI does. Indeed, I wouldn't trust a database that gives you that kind of power. Why? Because some of a database's best features, like the ACID guarantees, require never giving certain kinds of control back to anybody except a handful of really, really smart guys at Oracle.
Schema change is irrelevant, its hidden in the procedure. Your code no longer cares about mundane 'schema'.
Yeah, if you completely hide the fact that it's a SQL database, then you can get a clean API. We're proposing the same solution, which is to completely hide the database. We're just talking about doing it at different levels.
Personally, I think the better developer tools, the bigger pool of developers, and the lack of vendor lock-in all point to putting that clean API outside of the database, not in it. But as I've mentioned elsewhere in this thread, I think there are circumstances where it can make sense to put the core of the app in the database.
Of course, either way you lose the much-touted ability to use the database as a general-purpose tool. But I think that's fine. No matter where you put your business logic, I don't think you should let people run arbitrary SQL against your production servers. If they need to do weird stuff, let them do it against a copy of the data on server where their quadruple-nested SELECTs and sloppy UPDATEs won't screw with the production apps.
It's called 'you get what you pay for.' Consumer-grade stuff is cheap - when you buy it, you have to expect corners to be cut.
It could be that the guys at Linksys did a full cost/benefit analysis, that they determined that the price of additional ROM or a little extra development was just more expensive than the time and money lost to support calls and free replacement hardware, and the lost consumer confidence.
But my guess is that it just didn't occur to them. They're used to making uncomplicated things for a technical audience. They still haven't fully figured out that they're a consumer products company, making things for people with no technical savvy, whose main means of resolving a problem is power-cycling the hardware and seeing if it gets better. And when it doesn't get better, they say, "Boy, Company X makes crappy stuff. I'll buy from Company Y from now on."
Well then, you better not buy anything with upgradable firmware. Perhaps there are devices that can survive having an upgrade interrupted, but I've never seen any.
They certainly exist.
The Ascend Pipeline ISDN routers had enough flash space for two ROM images. When upgrading, it would write the new image into unused space; only when it was fully uploaded and verified would it mark it as the active image.
It's also perfectly possible to put a simple boot loader in ROM that has just enough brains to either boot the flash image or to let you rewrite the flash. Nobody expects to have to send their computer back to the factory if they screw up an OS upgrade; they just boot from an alternate medium. There's no technical reason appliances can't do that, and there are great customer-service reasons why they should.
Just what do you think would constitute good customer service on their part if replacing a dead unit with a working one isn't to your satisfaction? Just what do you want out of Linksys? Blood?
Uh, how about making hardware that can't be destroyed by normal user behavior? Just a thought.
Hibernate is the way to go to avoid the impedance between OO and RDBMS.
Let me give an amen here. If you are using an SQL-based database with Java, Hibernate keeps about 95% of the database-related shennanigans completely out of your Java code. Sooooo many Java object models are hideously distorted to match some unmigratable schema, and a good O/R mapping framework Hibernate makes it much easier to write good, clean OO code.
You know nothing about database-backed application development. [...] You've never used a database, obviously. [...] You've never worked for a real company, have you?
Say, you may not get out much, but there are other ways to build an app besides on top of an SQL server. You'll note that Doom 3, Microsoft Word, and the Google search engine don't use them. You'll concede that those are all real apps produced by real companies, right?
I'll argue that there are zero high level programming languages that allow the granulaity of control that a real RDBMS allows.
A little reminder here: databases aren't made from magic pixie dust; they're written in other languages. An RDBMS can't be more granular than the language it's written in, it can only be less. Indeed, it probably should be less, as its purpose is to make development simpler, easier.
The only question here is when it's more cost-effective to use an RDBMS on a given project. Back before DBMSes existed, people wrote a lot of low-level code to get things done. But eventually people pulled some of that code into common libraries for managing records, and the DBMS was born. If you're doing the kinds of things that Oracle expects in a way that Oracle expects, using an Oracle server may save you a lot of money and development time.
But if you're Google, an off-the-shelf DBMS is a big waste of time. Oracle's a great general-purpose engine, but Google engineers don't give a damn about the general case. They are building an utterly specific application; the generality of a database server mainly gets in their way.
So ease off on the "If you don't use a database you must be an ignorant fool," crap, ok? The parent poster was clearly inflamatory, but he describes one perfectly reasonable way to build successful applications. His isn't the only way, and neither is yours.
The idea of a database is to put the whole data-relation logic in the database, if only to insure atomicity of operations.
There are other ways to do that. Prevayler is one that works just fine.
Because as soon as you rely on an external process to maintain data integrity, you're bound to fall prey to some sloppy programmer who does not understand the data relationships and will not properly maintain the data integrity.
If you have a bad programmer working on bad code, that's probably true. In good code in an OO language, you have three lines of defense.
The first is the object interface itself. If the object interface doesn't have a way to change something, then there's no way to break it externally.
The second is the internal object code. It should be written in such a way that the integrity requirements are clear. A developer mucking around in the object's code should be able to tell what the important bits are.
The third is the unit tests. Not only will they document the purpose and nature of the object, but they will also prevent a careless developer from breaking something important.
For me, this provides a lot more utility than a set of stored procedures does. YMMV, of course, but using the database to warn you about bad code strikes me as a pretty roundabout approach.
Contrast this with the fact that just about every language supports a database connectivity that allows calling stored procudures. So their perl code logs into your database and calls your API -- easy.
Until you need to do a schema change. Then you're stuck, because you've got stuff in just about every language calling your database directly.
Your spiffy java API for checking whether a series of transactions is properly ordered isn't callable from their COM object or vice versa.
Then put a simple socket interface on your Java API. Pretty much every language that talks SQL can talk over a socket. Then you have a single clean interface with just what you need, rather than a big, complicated interface that people will access in all sorts of ways that the original design won't expect.
Alternatively if it's about data, it should be in the DB. i.e 'Users have a Type which can't be null unless the user is Inactive'.
Maybe this is true for procedural languages. But for OO languages, your objects should never be able to get in invalid states. If they can, it's usually a sign of poor design OO or poor unit testing.
If your developers are writing code that's putting bad data into the database, I'd say you should fix the code rather than duplicating rules about the data in two places. And if you can't fix the code, then fix the process that produces the code.
If, in the interim, I wanted to make sure nothing bad got in the database, I might use stored procedures. But instead I mightwrite a consistency checker that ran at night, rather than putting a lot of hopefully redundant code in the critical path for my apps.
But aren't bottlenecks unavoidable when any absent person's code is causing problems?
In a word, no. You may have chosen not to avoid it, but it's not necessary. If you use a team-oriented approach like Extreme Programming, all the developers own the code. If somebody is absent, work goes on. You wouldn't negligently build an app with a single point of failure. Why would you build a team that way?
Sometimes there are different front ends to the same data, incoming interfaces, etc. They tend to grow on databases as time passes by:)
This pattern, where database-as-repository turns into database-as-integration-layer, strikes me as the road to hell, albeit a tempting and convenient one.
Why? Because as soon as you have two or more code bases trying to work with the same schema, you are effectively screwed. Mortals have a hard enough time evolving a schema when there's just one code base to update; I've never seen anybody successfully and regularly migrate a schema and several different code bases at the same time. Instead, they end up with massive hack jobs, eventually devolving into the classic, "We've got to rewrite everything from scratch," as if the bits had somehow rotted beyond repair.
Forget that, I say. If you need an integration layer, just build it.
Slashdot Mirror
Well I don't believe that most people outside of the US are in a good position to understand US politics.
Yeah, that's nearly as crazy an idea as some Frenchman writing an enduring classic about American democracy. There's plenty of good foreign-press coverage of the US. A prime example is The Economist.
Wow, great comment from somebody who actually lives in Switzerland. Mods, please bump this one up.
I used to make this argument myself, by I no longer find it persuasive for guns.
There are quite a number of things we regulate because they have the potential to be dangerous. Cars are a great example. Their primary purpose is to get people places, but we place a lot of restrictions on who can have a car, how much training they need, and what kind of car they can have. Explosives are another example; you wanna do pyrotechnics, you have to get a license.
Guns, especially the guns people are interested in regulating, have a primary purpose of killing people. I agree they should be legal, but I think they should be regulated much more heavily than cars.
For example, Switzerland has a high incidence of gun ownership but low incidence of gun violence; people say that's because there everybody serves time in the military. I also note that people are wealthier and saner there. So maybe for gun ownership we should require a minimum of a 12-week boot-camp-style training on proper gun use, plus yearly 1-week refreshers.
The serious gun owners I know also keep their weapons unloaded and locked up when not in use. So perhaps we could add mandatory secure, theft-proof storage for guns, with random checks. And for any gun owner whose gun ends up killing someone, suicide, homicide or accident, there's minimum 2-year sentence for negligence.
I agree that the problem is mainly stupid or crazy people with guns. But if smart, sane people want to keep their guns, they'll have to find a way to make sure that the stupid and the crazy don't get guns.
Yeah, years of reading the excellent and very numerate general newsweekly The Economist have pretty much spoiled other media for me.
One big one that makes me crazy is use of percentage measures. E.g., a reporter will say that this year 10% of kids failed some test, and that this is up 3% from last year. So what was last year's value, 9.7% (a 3% difference) or 7% (a 3 percentage point difference, but a 43% increase)? Often, they say the former but mean the latter.
Another is the giving of numbers without context. For example, somebody will claim that a city's legal system is racially biased because X% of the people incarcerated are black. They might be right, but their number doesn't help me at all unless I also know what percentage of the city's population are black. And I've frequently heard about the shocking size of California's budget defecit of N billion dollars, but it's the rare article that tells me how big the whole budget is, or how big tax revenues are, or any number that might let me see how big the problem really is.
My interpretation of this: most journalists don't do math unless forced, so they never notice that it's impossible to do math with the numbers they give out.
One trading company I worked for would order a few cases of beer and other drinks in every Friday afternoon. Nobody had to participate, but even the non-drinkers would usually stop work and hang out with the rest.
It was great. It got people talking in a way that wouldn't have happened during the work day. Not only did it make people feel generally closer to their colleagues, but the cross-polination meant a lot of great ideas came up that never would have happened otherwise.
heh. work hasn't been fun in a while. chances are pretty slim i could get these corporate to spring for this type of system - it may motivate people, and we wouldn't want that.
Just buy it. Somebody on Slashdot taught me this great trick: just pretend that 1% of your salary is a bonus from the company to take care of little things that their budgeting process is too clumsy and stupid to deal with.
Sure, the text might be helpful, but I think much of the value of this article comes from the images that go with it. E.g., this one.
No, really, they use a bunch of illustrations like this in the linked article. It dumbfounds me.
Good code, in no particular order:
I agree with all of these. A couple of notes:
Reuses, and is reusable, where sensible
Yes, especially that last part. A lot of developers talk about reusability, when what they're really doing is gold-plating, adding unused library features.
Is documented (Javadoc stylee, for preference!)
Maybe. I used to write a lot of documentation, but since I've started doing test-first development, I don't really much of it anymore. Why? Because A) I have a good suite of unit tests that document the functionality in a way that can be automatically verified, and B) doing good unit tests encourages you to break things down into small, testable chunks, which are easier to understand.
I know some programmers who have a decent amount of technical ability, but write such convoluted code that it's useless to others. This is worthless to me. They may as well not have coded anything, since it typically takes more time to figure out what's going on than it would to re-write from scratch. I don't consider such a person a good programmer, and I wouldn't hire any of them.
Agreed. For a personal project, that's fine. But in a business, you're hopefully creating code that will last a long time, longer than any single person would want to be responsible for maintaining it.
The reality is that people go on vacation, change projects, they leave jobs, they change careers, and they even die from time to time. If a body of code is so idiosyncratic that only the original programmer can deal with it, then that code will have to be thrown out sooner or later. Why would a business want to invest in a chunk of code when its lifespan will only be as long as one guy stays around?
As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
First off, schema changes are pretty rare once you have production data. Sometimes you add fields and tables, but almost never do you refactor the data model because either you can map your existing data, which proves you haven't achieved any benefit, or you can't which proves you've achieve negative benefit.
For you, perhaps. In my experience, schema changes happen fairly frequently as we add new features or refactor the code base so that it more clearly expresses our understanding of the system.
I think the reason most people don't change their schemas is because they're hard to change. Once I did the work to made them easy to change, I was surprised how often we changed them.
As for programming java-to-COM using a socket, I've actually done that, but trying to get another organization to write their side of such an interface is usually a blank-stare generator. They would probably think for a while and suggest using ODBC instead.
There's nothing wrong with doing that, then. If the protocol they want ends up looking a lot like SQL queries or SQL stored procedure calls, then that's a fine way to write a protocol. Or you can point them at one of the pre-built toolkits for web service APIs; that may be enough of a starter that they think it's just as easy as doing SQL.
They work on personal projects while at work.
There's some truth to this.
Good developers like exploring new technologies and trying new things out. That's how they stay good developers. Smart companies allow for this. Some places, like Google, have formal policies saying that it's ok to spend a certain percentage of your time on personal projects. At others, it's an informal thing.
The alternatives are to a) make your developers miserable, driving away the good, creative ones, or b) make them sneaky. Neither is such a good thing.
Typical poppycock from a spoon-fed Java kid.
It works for me. My bug rates in production are below one per developer-month, and have been for a few years now. How about you?
There are other programming languages than Java in life.
Yes! I've used many of them in the 20 years I've been writing code. I'm not saying that good OO code is the only way to program; I'm just saying that it is one way that has worked for me, and sharing some tips on the right way to do it. What are you so defensive about?
What you are describing is a fine way to lock 1u3ers into using a single platform.
And which platform would that be? There are at least three independent Java JVMs, all implemented from a published spec, running on at least five different processors under at least four different operating systems, some of which are available from dozens of vendors.
Using Java could mean you're locked into the Java language. But really, it doesn't even mean that. If you want a public API to your app you're going to have to write one. Whether that's SQL stored procedures or Java-backed SOAP or any one of a dozen other reasonable choices is a local decision; there is no universal answer.
Doing team-oriented stuff in a small shop is much easier that trying to do it on a large scale. If you only have three developers, there might be only one SQL expert, but that doesn't mean that there has to be only one person writing SQL code. At worst, it means that the SQL expert should pair with (or, less effectively, review the work of) developers doing the SQL work.
Extreme Programing isn't always an economically practical option.
I think that's true, but relatively rare. The productivity, reliability, and business agility gains are substantial. It's my experience that you get more features delivered for the money using agile methods than traditional ones.
You're right, that's why JVMs don't have garbage collection or strong typing, because JVMs are written in C, and C doesn't. Oh, wait. It looks like software can have features that its host language doesn't. How 'bout that?
That's an interesting point, but a) it's one I agree with, and b) it's nothing to do with my point. I was answering NineNine's claim about about granularity of control. In Java, you can have garbage collection precisely because you give up control over memory allocation and deallocation. I think that's a worthwhile tradeoff most of the time.
An SQL database gives some very cool features, like the ability for non-experts to sit down and hack out queries to do ad-hoc reporting. But you give up a lot of granularity of control to get that. Various proprietary vendor extensions let you claw some of that control back, but I don't know of any that let you get all of it back in the same way that Java's JNI does. Indeed, I wouldn't trust a database that gives you that kind of power. Why? Because some of a database's best features, like the ACID guarantees, require never giving certain kinds of control back to anybody except a handful of really, really smart guys at Oracle.
Schema change is irrelevant, its hidden in the procedure. Your code no longer cares about mundane 'schema'.
Yeah, if you completely hide the fact that it's a SQL database, then you can get a clean API. We're proposing the same solution, which is to completely hide the database. We're just talking about doing it at different levels.
Personally, I think the better developer tools, the bigger pool of developers, and the lack of vendor lock-in all point to putting that clean API outside of the database, not in it. But as I've mentioned elsewhere in this thread, I think there are circumstances where it can make sense to put the core of the app in the database.
Of course, either way you lose the much-touted ability to use the database as a general-purpose tool. But I think that's fine. No matter where you put your business logic, I don't think you should let people run arbitrary SQL against your production servers. If they need to do weird stuff, let them do it against a copy of the data on server where their quadruple-nested SELECTs and sloppy UPDATEs won't screw with the production apps.
It's called 'you get what you pay for.' Consumer-grade stuff is cheap - when you buy it, you have to expect corners to be cut.
It could be that the guys at Linksys did a full cost/benefit analysis, that they determined that the price of additional ROM or a little extra development was just more expensive than the time and money lost to support calls and free replacement hardware, and the lost consumer confidence.
But my guess is that it just didn't occur to them. They're used to making uncomplicated things for a technical audience. They still haven't fully figured out that they're a consumer products company, making things for people with no technical savvy, whose main means of resolving a problem is power-cycling the hardware and seeing if it gets better. And when it doesn't get better, they say, "Boy, Company X makes crappy stuff. I'll buy from Company Y from now on."
Well then, you better not buy anything with upgradable firmware. Perhaps there are devices that can survive having an upgrade interrupted, but I've never seen any.
They certainly exist.
The Ascend Pipeline ISDN routers had enough flash space for two ROM images. When upgrading, it would write the new image into unused space; only when it was fully uploaded and verified would it mark it as the active image.
It's also perfectly possible to put a simple boot loader in ROM that has just enough brains to either boot the flash image or to let you rewrite the flash. Nobody expects to have to send their computer back to the factory if they screw up an OS upgrade; they just boot from an alternate medium. There's no technical reason appliances can't do that, and there are great customer-service reasons why they should.
Just what do you think would constitute good customer service on their part if replacing a dead unit with a working one isn't to your satisfaction? Just what do you want out of Linksys? Blood?
Uh, how about making hardware that can't be destroyed by normal user behavior? Just a thought.
Hibernate is the way to go to avoid the impedance between OO and RDBMS.
Let me give an amen here. If you are using an SQL-based database with Java, Hibernate keeps about 95% of the database-related shennanigans completely out of your Java code. Sooooo many Java object models are hideously distorted to match some unmigratable schema, and a good O/R mapping framework Hibernate makes it much easier to write good, clean OO code.
You know nothing about database-backed application development. [...] You've never used a database, obviously. [...] You've never worked for a real company, have you?
Say, you may not get out much, but there are other ways to build an app besides on top of an SQL server. You'll note that Doom 3, Microsoft Word, and the Google search engine don't use them. You'll concede that those are all real apps produced by real companies, right?
I'll argue that there are zero high level programming languages that allow the granulaity of control that a real RDBMS allows.
A little reminder here: databases aren't made from magic pixie dust; they're written in other languages. An RDBMS can't be more granular than the language it's written in, it can only be less. Indeed, it probably should be less, as its purpose is to make development simpler, easier.
The only question here is when it's more cost-effective to use an RDBMS on a given project. Back before DBMSes existed, people wrote a lot of low-level code to get things done. But eventually people pulled some of that code into common libraries for managing records, and the DBMS was born. If you're doing the kinds of things that Oracle expects in a way that Oracle expects, using an Oracle server may save you a lot of money and development time.
But if you're Google, an off-the-shelf DBMS is a big waste of time. Oracle's a great general-purpose engine, but Google engineers don't give a damn about the general case. They are building an utterly specific application; the generality of a database server mainly gets in their way.
So ease off on the "If you don't use a database you must be an ignorant fool," crap, ok? The parent poster was clearly inflamatory, but he describes one perfectly reasonable way to build successful applications. His isn't the only way, and neither is yours.
There are other ways to do that. Prevayler is one that works just fine.
Because as soon as you rely on an external process to maintain data integrity, you're bound to fall prey to some sloppy programmer who does not understand the data relationships and will not properly maintain the data integrity.
If you have a bad programmer working on bad code, that's probably true. In good code in an OO language, you have three lines of defense.
For me, this provides a lot more utility than a set of stored procedures does. YMMV, of course, but using the database to warn you about bad code strikes me as a pretty roundabout approach.
Contrast this with the fact that just about every language supports a database connectivity that allows calling stored procudures. So their perl code logs into your database and calls your API -- easy.
Until you need to do a schema change. Then you're stuck, because you've got stuff in just about every language calling your database directly.
Your spiffy java API for checking whether a series of transactions is properly ordered isn't callable from their COM object or vice versa.
Then put a simple socket interface on your Java API. Pretty much every language that talks SQL can talk over a socket. Then you have a single clean interface with just what you need, rather than a big, complicated interface that people will access in all sorts of ways that the original design won't expect.
Alternatively if it's about data, it should be in the DB. i.e 'Users have a Type which can't be null unless the user is Inactive'.
Maybe this is true for procedural languages. But for OO languages, your objects should never be able to get in invalid states. If they can, it's usually a sign of poor design OO or poor unit testing.
If your developers are writing code that's putting bad data into the database, I'd say you should fix the code rather than duplicating rules about the data in two places. And if you can't fix the code, then fix the process that produces the code.
If, in the interim, I wanted to make sure nothing bad got in the database, I might use stored procedures. But instead I mightwrite a consistency checker that ran at night, rather than putting a lot of hopefully redundant code in the critical path for my apps.
But aren't bottlenecks unavoidable when any absent person's code is causing problems?
In a word, no. You may have chosen not to avoid it, but it's not necessary. If you use a team-oriented approach like Extreme Programming, all the developers own the code. If somebody is absent, work goes on. You wouldn't negligently build an app with a single point of failure. Why would you build a team that way?
Sometimes there are different front ends to the same data, incoming interfaces, etc. They tend to grow on databases as time passes by :)
This pattern, where database-as-repository turns into database-as-integration-layer, strikes me as the road to hell, albeit a tempting and convenient one.
Why? Because as soon as you have two or more code bases trying to work with the same schema, you are effectively screwed. Mortals have a hard enough time evolving a schema when there's just one code base to update; I've never seen anybody successfully and regularly migrate a schema and several different code bases at the same time. Instead, they end up with massive hack jobs, eventually devolving into the classic, "We've got to rewrite everything from scratch," as if the bits had somehow rotted beyond repair.
Forget that, I say. If you need an integration layer, just build it.