I recently attended a legal studies lecture in which the professor (a lawyer) asserted that if any of us were to participate in such a program and any disease or predisposition for disease were discovered, that we would be legally obligated to make this known to any potential medical insurers the next time we apply for medical insurance. According to this lawyer, failure to disclose in this manner would result in annulment of the insurance should the failure be discovered.
Therefore, only those with salaries at a higher order of magnetude will still live comfortably.
This conclusion makes sense in the context of your argument, but in the wider context of reality it is somewhat flawed: Yes, prices on items will go up as resources become more scarce, but as technology, productivity, and know-how improve, those same items will also provide more comfort per unit of raw material and labor. So it won't just be the top rungs that "live comfortably", but the bottom rungs will too--perhaps less comfortably, but comfortably nonetheless.
There will always be those who live orders of magnitude more comfortably than others; the important thing is that globalization will bring some measure of comfort to those in second and third world countries, by allowing them to contribute to the overall productivity of the world rather than drain it.
I'd rather pay 3 cents more per minute to be able to use any old phone to call any old phone, then have to install special software and use a network-bound computer to call other network-bound computer; that's what email's for. To call a real phone using Skype, it's 1.7 Euros per minute! -- And you still need to install software on your outbound computer!
I've been using them for years. Not sure what technology they are using, but it's hard to beat their international rates. Here's a sampling (this in only about 1/20th of their complete list):
Afghanistan $0.475 Antarctica - Casey $0.600 Antarctica - Scott $0.600 Australia $0.045 Belgium $0.055 Brazil-Sao Paulo $0.055 Chile $0.045 China-Bejing $0.050 Czech Republic $0.045 France $0.050 Germany $0.050 Ghana $0.135 Hong Kong $0.049 India $0.195 Iran $0.159 Iraq $0.520 Israel-Tel Aviv $0.050 Italy $0.050 Japan $0.055 Netherlands $0.038 New Zealand $0.044 Russia-Moscow $0.038 United Kingdom $0.035 Zimbabwe $0.105
Take any application thats maintained by sloppy developers over several years all working together, and the same thing tends to happen.
That's true, but the negative effects are much more pronounced when the language is procedural rather than object oriented with a well-thought-out class structure. It's even worse when the use of SPs is arbitrary.
Ok. Whats your 'data'? Letting the database be the master of a char(13), instead of letting it take the commands needed to store a phone number. You have it exactly right. I like the database to BE the master of my data. That's not to say that buisness logic needs to be contained within the store procedures, but the DATA logic does.
Often times "data logic" is business logic. It's funny you should mention phone numbers, because I'm actually facing this exact problem right now: some of the 3rd parties with which I have to integrate need their phone numbers in one format, and some in other formats. They (probably) have systems where phone number formatting has been hardcoded into SPs, so they can't be flexible with me. So I have to be flexible, and thus hardcoding phone formatting into an SP is not an option for me, unless I want to edit my SP every time I've got a new 3rd party to deal with and get pasta all over my hands.
One big problem with stored procedures is that they're exactly that--procedural. And procedural code _does_ have a greater tendancy to tend toward spaghetti than well-designed OO stuff (both have the tendancy, but it's worse with SPs).
WHY isnt it as easy to add more database servers then it is to add more web servers?
Because then you have to deal with more of those people who manage data and databases (kidding, of course--50% of the db people I have dealt with have been very good to work with; it's that other 50% that make life miserable and force simple developers like me to get all wrapped up in politics).
Stored procedures come in handy once in a while, but mainly they've caused me enourmous headaches--especially when you run into applications that have a 100K lines of stored procedures mixed with another 100K lines of application-level database layer code, and it's impossible to figure out by what perverted formula it was originally determined what to put into stored procedures and what not to put into stored procedures. In the systems that I've seen, the stored procedure code has over many years become unmanageable spaghetti following no coding conventions, with half of the procedures being completely obsolete. Perhaps this isn't so much an argument against SPs as it is an insult to the kind of people who tend to write them.
Personally, I like leaving the database to being the master of my data, and it being a slave to my application: application wants data, database gives application data; application tells database to store data, database stores data. It just seems proper that way.
I would feel a lot more comfortable and happy about stored procedures in a system where the stored procedures acted as a complete abstraction of the data--so that the application only communicates with the stored procedures and never directly reads or writes tables--in fact, the application has no knowledge whatsoever about the tables. That seems like it would be proper too.
The situation that is not proper is the situation where stored procedures play no clearly defined role, and developers are continually asking the question, "Should I do this in a SP or not?" Then what you end up with is a nightmare that can only be solved by hiring someone like me to come in and unscramble everything and put everything into nice little buckets that make sense.
...stolen software that phones home is kind of like those car thingies that emit their exact location when the car is stolen...I'm sure car thieves hate those thingies. Now wouldn't the car thingie be cool if it could not only tell you its exact location, but also the name and serial number of the guy who stole it!
Slashdot Mirror
I recently attended a legal studies lecture in which the professor (a lawyer) asserted that if any of us were to participate in such a program and any disease or predisposition for disease were discovered, that we would be legally obligated to make this known to any potential medical insurers the next time we apply for medical insurance. According to this lawyer, failure to disclose in this manner would result in annulment of the insurance should the failure be discovered.
Therefore, only those with salaries at a higher order of magnetude will still live comfortably.
This conclusion makes sense in the context of your argument, but in the wider context of reality it is somewhat flawed: Yes, prices on items will go up as resources become more scarce, but as technology, productivity, and know-how improve, those same items will also provide more comfort per unit of raw material and labor. So it won't just be the top rungs that "live comfortably", but the bottom rungs will too--perhaps less comfortably, but comfortably nonetheless.
There will always be those who live orders of magnitude more comfortably than others; the important thing is that globalization will bring some measure of comfort to those in second and third world countries, by allowing them to contribute to the overall productivity of the world rather than drain it.
Oops, sorry, misread, 1.7 Euro cents per minute. But you still need the software and the computer.
I'd rather pay 3 cents more per minute to be able to use any old phone to call any old phone, then have to install special software and use a network-bound computer to call other network-bound computer; that's what email's for. To call a real phone using Skype, it's 1.7 Euros per minute! -- And you still need to install software on your outbound computer!
I've been using them for years. Not sure what technology they are using, but it's hard to beat their international rates. Here's a sampling (this in only about 1/20th of their complete list):
Afghanistan $0.475
Antarctica - Casey $0.600
Antarctica - Scott $0.600
Australia $0.045
Belgium $0.055
Brazil-Sao Paulo $0.055
Chile $0.045
China-Bejing $0.050
Czech Republic $0.045
France $0.050
Germany $0.050
Ghana $0.135
Hong Kong $0.049
India $0.195
Iran $0.159
Iraq $0.520
Israel-Tel Aviv $0.050
Italy $0.050
Japan $0.055
Netherlands $0.038
New Zealand $0.044
Russia-Moscow $0.038
United Kingdom $0.035
Zimbabwe $0.105
Google to find their home page.
Take any application thats maintained by sloppy developers over several years all working together, and the same thing tends to happen.
That's true, but the negative effects are much more pronounced when the language is procedural rather than object oriented with a well-thought-out class structure. It's even worse when the use of SPs is arbitrary.
Ok. Whats your 'data'? Letting the database be the master of a char(13), instead of letting it take the commands needed to store a phone number. You have it exactly right. I like the database to BE the master of my data. That's not to say that buisness logic needs to be contained within the store procedures, but the DATA logic does.
Often times "data logic" is business logic. It's funny you should mention phone numbers, because I'm actually facing this exact problem right now: some of the 3rd parties with which I have to integrate need their phone numbers in one format, and some in other formats. They (probably) have systems where phone number formatting has been hardcoded into SPs, so they can't be flexible with me. So I have to be flexible, and thus hardcoding phone formatting into an SP is not an option for me, unless I want to edit my SP every time I've got a new 3rd party to deal with and get pasta all over my hands.
One big problem with stored procedures is that they're exactly that--procedural. And procedural code _does_ have a greater tendancy to tend toward spaghetti than well-designed OO stuff (both have the tendancy, but it's worse with SPs).
WHY isnt it as easy to add more database servers then it is to add more web servers?
Because then you have to deal with more of those people who manage data and databases (kidding, of course--50% of the db people I have dealt with have been very good to work with; it's that other 50% that make life miserable and force simple developers like me to get all wrapped up in politics).
Stored procedures come in handy once in a while, but mainly they've caused me enourmous headaches--especially when you run into applications that have a 100K lines of stored procedures mixed with another 100K lines of application-level database layer code, and it's impossible to figure out by what perverted formula it was originally determined what to put into stored procedures and what not to put into stored procedures. In the systems that I've seen, the stored procedure code has over many years become unmanageable spaghetti following no coding conventions, with half of the procedures being completely obsolete. Perhaps this isn't so much an argument against SPs as it is an insult to the kind of people who tend to write them.
Personally, I like leaving the database to being the master of my data, and it being a slave to my application: application wants data, database gives application data; application tells database to store data, database stores data. It just seems proper that way.
I would feel a lot more comfortable and happy about stored procedures in a system where the stored procedures acted as a complete abstraction of the data--so that the application only communicates with the stored procedures and never directly reads or writes tables--in fact, the application has no knowledge whatsoever about the tables. That seems like it would be proper too.
The situation that is not proper is the situation where stored procedures play no clearly defined role, and developers are continually asking the question, "Should I do this in a SP or not?" Then what you end up with is a nightmare that can only be solved by hiring someone like me to come in and unscramble everything and put everything into nice little buckets that make sense.
...stolen software that phones home is kind of like those car thingies that emit their exact location when the car is stolen...I'm sure car thieves hate those thingies. Now wouldn't the car thingie be cool if it could not only tell you its exact location, but also the name and serial number of the guy who stole it!