Not sneaky, just lazy consumers. People should really read statements like "Up to 6.7Mb/s" as "I have no idea how fast it will be, but it won't be higher than 6.7Mb/s". Unfortunately, people read it as "Pretty close to 6.7Mb/s". A more interesting variant is "Up to 15% off or more", which really means absolutely nothing, as in, any number satisfies the given constraint. If people read these statements literally, they wouldn't buy services based on them and marketers would have to come up with new statements. Unfortunately, we gobble these things up. People give me crap all the time for being too literal, but I think the whole world has gone way overboard the other way.
I'm posting this from a 1920x1200 24" monitor that I bought three years ago for about $200.00. Almost nobody makes an affordable display with more than 1080 rows any more. You can blame HDTV for it, monitor manufacturers would much rather sell computer users the HDTV screens they are already making than create computer-specific resolutions. Before HDTV, monitors were on a steady march to higher resolution, after 1080p became popular, monitors backtracked and have been stuck ever since.
Except the PowerPoint part. Back when I went to school, professors used one of the old-fashioned projectors that display whatever was on a clear sheet of plastic onto the wall. They started class with a few pre-printed sheets, a big roll of blank plastic, and a few markers. It was just like PowerPoint, except much more dynamic. It was like a chalkboard, except you could go back to previous drawings. One of the big problems with PowerPoint is that the entire lecture has to be planned out in advance and any deviation from the plan cannot be accomodated by PowerPoint.
So why did she go to the school that doesn't have the local facilities to teach the classes that she needs to take? We're not talking about a few liberal arts classes, this is senior year specialization classes. I have an engineering degree and I know that the only part that isn't "cookie cutter" is the senior year. By cookie cutter, I mean the foundational classes that almost every engineering specialty needs. She's going to end up with a degree in Biomedical Engineering from school "X", where school "X" isn't known for Biomedical Engineering, instead of the school that actually runs the classes. When she goes for a job, people are only going to look at two things about her education, what degree she has and where it came from. It doesn't even matter if she gets the exact same education as students from the other school, she won't get the same degree.
My opinion has always been that university is all about "punching your ticket". For $50,000, I'd make sure the right hole gets punched.
That is exactly the case where longer yellows work. There is almost always a short delay between the red on one side and the green on the other, plus it takes a bit for the cars that just got the green to accellerate into the intersection. To t-bone a car, you would need to run the red by at least five seconds. No judgement call on a yellow is ever going to end up with you embedded in the passenger door of a minivan.
T-bones are caused by people running a red light when it has been red a very long time. These accidents are not prevented by cameras.
Another factor is that it is way too expensive to re-provision. Where I work, you might as well ask for 5 times what you need, because if you go back and ask for an increase, the labor to do it costs more than the storage. I really shouldn't take 20 hours of someone's time to make my LUN bigger, but that's what the storage team will bill me for. If re-provisioning only required that you pay for the additional storage, I wouldn't worry about it.
Good storage virtualization fixes most of these problems, but it seems like nobody wants to invest in it.
It's likely a small decrease in t-bones. You don't really think that people who run red lights and hit cars are making a rational decision, do you? Most t-bones accidents are caused by inattention, adding the risk of a $100 fine to the already existing risk of dying doesn't really make enough difference to make them pay attention. Think about it, if "death" isn't a deterrent, then why would "death + $100" work?
It's been shown many times that increasing the yellow duration really does prevent people from running red lights. Most people don't have the mental bandwidth to remember the relative durations of all the yellow lights they might encounter.
A countdown is very similar to an earlier yellow, but it only works at low speed intersections. I drive on a lot of 55 mph roads with signals. I'm sure I wouldn't be able to read a standard pedestrian countdown timer at these lights early enough to matter.
In Ricki's case, he didn't understand how NTFS permissions on a folder combine with share level permissions when you're accessing over the network.
Funny that this is a classic case where a foundations-based education would have avoided the problem in the first place. Although you have the outcome right, are "Gavin"-ing the explanation. Learning to think critically is much more important than learning facts. If you never learn how share and NTFS permission combined, you can still come to the correct conclusions. Let's look at an analogous situation with a car -- Suppose you have to get to work and you work on an island, but live on the mainland. You have a bridge toll pass, but you lost your car keys. Can you get to work? Although this is an easy question, it is analogous in that we have two independent access control points, one path-based (share permissions) and one path-independent (NTFS permissions). Here's the rediculous question: How do your car keys combine with your toll pass?
NTFS permissions don't combine with share permissions. They are both simply potential impediments to reaching a specific goal. Any talk about combining them leads to needing to learn N*(N-1) combinations of things instead of N things and a few simple combination scenarios. N*(N-1) gets large fast, so this learning pattern will limit your potential.
BTW, what if you had the car keys, but not the toll pass, and you lived on the island? (Analogous to local access bypassing share permissions) What if you used the other bridge? (Do you have a pass for it? Analogous to using a different share that exposes the same file).
A contract cannot remove rights granted by an act of congress (Magnussen-Moss Warranty Act). Just because Apple does it, doesn't mean it's legal. There are a lot of tricky details, but as a general rule a company cannot refuse to honor a warranty simply because they don't want to. Any contract language suggesting otherwise is void and may void larger parts of the contract. The more the refusal seems to be tied to locking in additional sales (app store), the more likely a court would frown upon the refusal.
Care to explain how you can say that "VPN" over WiFi is safe, but WiFi can never be safe?
History. People always seem so optimistic that the current flaws of wireless will be solved in the next six months, but they never are. I remember talking to friends ten years ago and listening to "pretty soon everything will be wireless". Since then, wireless has gone from 11Mb/s to 150Mb/s, where very few people get 150 in real life, plus it's shared bandwidth. Wired networking has gone to 1Gb/s as the cheap standard and 10Gb/s readily available in the wiring closet, this is dedicated bandwidth as everything is switched nowadays.
Wireless security has gone the same direction -- IPSec has been around longer than 802.11 (1995 vs. 1997). I can't remember any major attacks against IPSec in the 15 years it has been around, but every wireless security protocol has had at least one. Since the hardware vendors have refused to include a sane protocol, I've been recommending using one on top of wireless forever. The day a real end-to-end security protocol is included with a wireless standard, I'll change my recommendation. I'm not holding my breath, as the goal of wireless security is to keep unauthorized people off the network, not to protect each data stream from each other.
As for picking up CAT-5 signals from outside the building -- most offices have hundreds of CAT-5 wires running in bundles for much of their total distance. It would take some pretty hardcore equiptment to pick up a single data stream without the ability to wrap a pickup coil around a single wire. All it takes to pick up wireless network signals is a $30 card that comes preinstalled on laptops.
I've been telling people to use VPN over WiFi connections forever. Even better, put your wireless devices on the outside of the firewall, so they have no choice but to VPN in. This also makes giving a random guest access to your wireless no big deal. Any one who thinks wireless networking will ever be safer than an old-fashioned hub is deluding themselves.
Maybe people like me. My iPhone gets more reliable and faster service in my house than my Verizon DSL. I originally switched to AT&T from Verizon when I got my current job because I get no Verizon reception in my office. We are a really big company, so Verizon sent out a sales rep and two techs to make it better. They didn't get anywhere, people with Verizon phones still have to go outside to make a call (BTW, they get four bars right outside the door).
I ended up with an iPhone because AT&T didn't have any other good smart phones at the time, and I like AT&T's service. I didn't choose AT&T to get an iPhone.
SQL only runs as SYSTEM if you change the service account settings during install (in other words, not by default). Shell commands are not available unless the server is specifically configured for them using the "Surface Area Configuration Tool". Running as SYSTEM by default was fixed fourteen years ago and xp_cmdshell was disabled by default five years ago.
IIS improved seven years ago, not recently. Regardless of the reason for improvement, it did improve. IIS 6 and 7 both have excellent security records and both have a sound architecture.
Microsoft's far from perfect, but you've been holding a grudge for fourteen years. Did they eat your children?
Many applications such as Oracle, Apache, Tomcat etc typically run as SYSTEM on windows, and as their own users on unix.
So, many cross platform applications have bad security defaults when installed on Windows, but good defaults when installed on unix. That sound more like a frame job than bad security on Microsoft's part. The Microsoft equivalents (SQL Server and IIS) are configured properly by default. I'll bet that like IIS, at least two of the three don't run user threads as SYSTEM.
I'm pretty sure he was talking about an IEC C13 or C15. The C15 is a true kettle cord, and it will plug into a computer, so a lot of people think it belongs there. Most computers actually take a C13, but the C15 exceeds its specifications and can be used in place of a C13.
Our electricity may not be sufficient to run a 3KW appliance, but at least we don't kill any where near as many of our citizens by electrocution. Our plugs are almost begging to be touched, yours are rubber coated halfway up, so in theory you can never touch a lead while it is live, yet yours is still many times more dangerous. I'll use the stove to boil my water.
BTW, we also fuse our branch circuits way back at the entrance to the home at 15 or 20 amps. You nutcases run mains current through the whole damn house. I still get 24KW for my whole house, I just can't use it at all one outlet.
Oh..... and no one has ever gone into a rage after stepping on a plug that someone left on the ground in the US. Those plugs you guys have are freakin' sharp and have a nasty tendency to fall pointy side up.
Confirmed here too. My variant is that people suddenly become unable to perform simple tasks in the presence of a computer. I had one guy (with 20 years experience in front of computers) call me because a Windows install wasn't going so well. He gave me the normal "it won't let me install it". I asked him to read me every word on the screen, after five minutes I gave up and told him I'd fix it when I was there tomorrow. When I got in, the screen had a message on it that read "No drives were found". It was the biggest sentence on the screen and had a warning icon next to it. I proceeded to fix the problem (hard drive power cable loose), but not before snapping a picture with my cell phone. I showed him the picture later and he said "That wasn't there when I looked at it".
In this case, I think the goal to to shift the pain of low resale value back to the manufacturer. This will give them a real incentive to innovate and remove the inventive to simply lie to customers and tell them that the resale value will be just fine.
All the thing you mentioned leasing would do, we do today with propane tanks, but we don't lease them.
What? I'm not talking about someone substituting a value in a query with another (legal) value. I'm talking about people trying to insert clauses etc. Random ad-hoc SQL is heavily discouraged
Straw man argument. Stupid code is stupid. Stored procedures don't magically fix stupid code. I inherited a system where your exact example is done with a stored procedure. The idiots I took over from actually have a parameter in a stored procedure named @where_clause. It does exactly what it sounds like it does. So, the solution is actually code review and turning your brain on, not using stored procedures. Just because you happen to write good code by using stored procedures doesn't mean that using stored procedures contributed in any way to your writing good code.
By your logic, I could claim that stored procedures are a bad idea because they can be used to create dynamic SQL atrocities.
First of all, you've got some balls, which I admire, but you're too stupid to know when to shut up and you've needlessly crossed the line with me with this comment.
That was made with as assumption that you were like the previous ten thousand DBAs I've had this discussion with. Sorry if it was improperly directed at you, but it does apply to a lot of the readers of slashdot.
Back to my point. I've never claimed that going the "all data access goes through stored procedures" philosophy won't work. Your experience shows that it does. My claim is that it isn't the only way to skin this cat. Not using stored procedures has, for me, produced a more maintainable result. Everything you claim you get as a benefit from stored procedures, I also have in my data access layer. If two thing exhibit the same property, then that property is not unique to either of those things. Therefore, none of your positive experiences are reasons to choose stored procedures, unless those experiences aren't universal across all common solutions. For example, if you claimed that you must drive a Corvette to go 0-60 in under 5 seconds, you'd be wrong. All the evidence that a Corvette goes 0-60 in under 5 seconds wouldn't make you right. One shred of evidience that there is another way to go 0-60 in under 5 seconds proves the original statement false. I have evidence that all of those benefits that are enjoyed by stored procedure fans are also enjoyed by those employing a distinct non-SP data access layer.
Our discussion really boils down to two sides; your side claims that stored procedures are the only way to do it right, my side claims that there are many ways to do it right. I can't see how anyone could ever claim that there is no other way to do what they do. You'd have to have knowledge of every technology to make that claim.
Every claim you make, from control to logging, to performance tuning, to identifying issues and talking to those responsible to fix them, I can do. Only, I can do them better because I have better tools. Sure, sp_help2 works, but a.Net application profiler is a thousand times better.
I also like the handwaiving of the BLOB issue. Since you don't have a technical argument (because T-SQL is literally not equipped to solve the problem), you simply suggest that it isn't a data-layer issue. I could change the argument to something like custom encryption, but I refuse to make the same point twice. I'll take the dodge as a win in my column unless you address it.
Step back and let the DBA's do their job. That means egress / ingress over all apps which want to use the DB.
Unfortunately, that means that a significant portion of the business logic will end up in the database. Since the middle tier is now embedded in the database, it is impossible to ever create a three tier application.
I have 15 years experience with Microsoft SQL Server, and I have trained half of the DBAs in my geographic area (seriously, I have). Please don't talk to me like only a DBA could ever build a data access layer that works. It is perfectly valid to build a data access layer that happens to live one step physically removed from the database. It is still distinct from the application, so there is no risk of a lack of abstraction, only it exists somewhere other than in stored procedures. T-SQL is an old language. There are at least twenty languages that can do many tasks better than T-SQL. I can do just about anything in my data access layer, and much of it is impossible with stored procedures. As an example... if I had a system that stored sensitive pictures in a database as BLOBs, and my requirement changed so that all returned pictures should be watermarked so we could track any information leaks. I could simply go into my C# data access layer and add a handful of lines of code that would dynamically watermark the image as it is being retreived from the database. A data access layer written in T-SQL could never do this. T-SQL is a weak language.
Forcing stored procedures has costs. Modern technologies like LINQ to SQL don't work. Old curmudgeonly people known as DBAs constantly force you to restate all of your requirements and then say no to half of them because they don't have the talent to pull it off. Applications break after a change because it is assumed that the DBA knows who is calling a stored procedure, but that is a pure fallicy that can only be handled by manual documentation - the sort of documentation that us application developers are also good at (my development tool can do a dependency analysis with the click of a button).
Our old stored procedure based development architecture is fragile and breaks all the time on changes because it is so complicated to figure out what is being accessed. Our new non-stored procedure based architecture has been rock solid for five years and many updates. I'm not saying that stored procedures caused the problems in the old architecture, but I am saying that stored procedures were not sufficient to prevent data layer fragility. You are using the worst possible argument for stored procedures, "DBAs are smart and developers are stupid".
There is no way you will create more efficient DB code than a competent DBA, and you should not have to worry about the hinting / indexes / partitioned views etc that DBA's consider when making sure your stuff runs well.
The two cannot work in isolation. How would you create a covering index if a developer demanded all columns of a table be returned, but he didn't really need them? How do you performance tune an application that requests the details for 10,000 customers by calling the customer profile retreival procedure 10 thousand times? Unless everybody participates, it won't work well.
I hope you're not trying to tell me your DBA trusts your app writers to sanitize everything?
They better. Procedure calls are just as vulnerable to SQL injection as ad-hoc SQL. The only person is a position to stop SQL injection is the application developer. The damage has been done before the DBA's code is even called.
... the DBA loses control...
That is your real fear. You simply want to be involved in every project to jusify your existence and refuse to admit that there is any other way to write applications, because those other ways reduce your value to the organization. I understa
You too need a demonstration. BTW, I don't need stored procedures to handle permissions because all of my applications are three tier and frond end users can't even log in to the database server.
Slashdot Mirror
Not sneaky, just lazy consumers. People should really read statements like "Up to 6.7Mb/s" as "I have no idea how fast it will be, but it won't be higher than 6.7Mb/s". Unfortunately, people read it as "Pretty close to 6.7Mb/s". A more interesting variant is "Up to 15% off or more", which really means absolutely nothing, as in, any number satisfies the given constraint. If people read these statements literally, they wouldn't buy services based on them and marketers would have to come up with new statements. Unfortunately, we gobble these things up. People give me crap all the time for being too literal, but I think the whole world has gone way overboard the other way.
I'm posting this from a 1920x1200 24" monitor that I bought three years ago for about $200.00. Almost nobody makes an affordable display with more than 1080 rows any more. You can blame HDTV for it, monitor manufacturers would much rather sell computer users the HDTV screens they are already making than create computer-specific resolutions. Before HDTV, monitors were on a steady march to higher resolution, after 1080p became popular, monitors backtracked and have been stuck ever since.
Except the PowerPoint part. Back when I went to school, professors used one of the old-fashioned projectors that display whatever was on a clear sheet of plastic onto the wall. They started class with a few pre-printed sheets, a big roll of blank plastic, and a few markers. It was just like PowerPoint, except much more dynamic. It was like a chalkboard, except you could go back to previous drawings. One of the big problems with PowerPoint is that the entire lecture has to be planned out in advance and any deviation from the plan cannot be accomodated by PowerPoint.
So why did she go to the school that doesn't have the local facilities to teach the classes that she needs to take? We're not talking about a few liberal arts classes, this is senior year specialization classes. I have an engineering degree and I know that the only part that isn't "cookie cutter" is the senior year. By cookie cutter, I mean the foundational classes that almost every engineering specialty needs. She's going to end up with a degree in Biomedical Engineering from school "X", where school "X" isn't known for Biomedical Engineering, instead of the school that actually runs the classes. When she goes for a job, people are only going to look at two things about her education, what degree she has and where it came from. It doesn't even matter if she gets the exact same education as students from the other school, she won't get the same degree.
My opinion has always been that university is all about "punching your ticket". For $50,000, I'd make sure the right hole gets punched.
That is exactly the case where longer yellows work. There is almost always a short delay between the red on one side and the green on the other, plus it takes a bit for the cars that just got the green to accellerate into the intersection. To t-bone a car, you would need to run the red by at least five seconds. No judgement call on a yellow is ever going to end up with you embedded in the passenger door of a minivan.
T-bones are caused by people running a red light when it has been red a very long time. These accidents are not prevented by cameras.
Another factor is that it is way too expensive to re-provision. Where I work, you might as well ask for 5 times what you need, because if you go back and ask for an increase, the labor to do it costs more than the storage. I really shouldn't take 20 hours of someone's time to make my LUN bigger, but that's what the storage team will bill me for. If re-provisioning only required that you pay for the additional storage, I wouldn't worry about it.
Good storage virtualization fixes most of these problems, but it seems like nobody wants to invest in it.
It's likely a small decrease in t-bones. You don't really think that people who run red lights and hit cars are making a rational decision, do you? Most t-bones accidents are caused by inattention, adding the risk of a $100 fine to the already existing risk of dying doesn't really make enough difference to make them pay attention. Think about it, if "death" isn't a deterrent, then why would "death + $100" work?
It's been shown many times that increasing the yellow duration really does prevent people from running red lights. Most people don't have the mental bandwidth to remember the relative durations of all the yellow lights they might encounter.
A countdown is very similar to an earlier yellow, but it only works at low speed intersections. I drive on a lot of 55 mph roads with signals. I'm sure I wouldn't be able to read a standard pedestrian countdown timer at these lights early enough to matter.
In Ricki's case, he didn't understand how NTFS permissions on a folder combine with share level permissions when you're accessing over the network.
Funny that this is a classic case where a foundations-based education would have avoided the problem in the first place. Although you have the outcome right, are "Gavin"-ing the explanation. Learning to think critically is much more important than learning facts. If you never learn how share and NTFS permission combined, you can still come to the correct conclusions. Let's look at an analogous situation with a car -- Suppose you have to get to work and you work on an island, but live on the mainland. You have a bridge toll pass, but you lost your car keys. Can you get to work? Although this is an easy question, it is analogous in that we have two independent access control points, one path-based (share permissions) and one path-independent (NTFS permissions). Here's the rediculous question: How do your car keys combine with your toll pass?
NTFS permissions don't combine with share permissions. They are both simply potential impediments to reaching a specific goal. Any talk about combining them leads to needing to learn N*(N-1) combinations of things instead of N things and a few simple combination scenarios. N*(N-1) gets large fast, so this learning pattern will limit your potential.
BTW, what if you had the car keys, but not the toll pass, and you lived on the island? (Analogous to local access bypassing share permissions) What if you used the other bridge? (Do you have a pass for it? Analogous to using a different share that exposes the same file).
A contract cannot remove rights granted by an act of congress (Magnussen-Moss Warranty Act). Just because Apple does it, doesn't mean it's legal. There are a lot of tricky details, but as a general rule a company cannot refuse to honor a warranty simply because they don't want to. Any contract language suggesting otherwise is void and may void larger parts of the contract. The more the refusal seems to be tied to locking in additional sales (app store), the more likely a court would frown upon the refusal.
Care to explain how you can say that "VPN" over WiFi is safe, but WiFi can never be safe?
History. People always seem so optimistic that the current flaws of wireless will be solved in the next six months, but they never are. I remember talking to friends ten years ago and listening to "pretty soon everything will be wireless". Since then, wireless has gone from 11Mb/s to 150Mb/s, where very few people get 150 in real life, plus it's shared bandwidth. Wired networking has gone to 1Gb/s as the cheap standard and 10Gb/s readily available in the wiring closet, this is dedicated bandwidth as everything is switched nowadays.
Wireless security has gone the same direction -- IPSec has been around longer than 802.11 (1995 vs. 1997). I can't remember any major attacks against IPSec in the 15 years it has been around, but every wireless security protocol has had at least one. Since the hardware vendors have refused to include a sane protocol, I've been recommending using one on top of wireless forever. The day a real end-to-end security protocol is included with a wireless standard, I'll change my recommendation. I'm not holding my breath, as the goal of wireless security is to keep unauthorized people off the network, not to protect each data stream from each other.
As for picking up CAT-5 signals from outside the building -- most offices have hundreds of CAT-5 wires running in bundles for much of their total distance. It would take some pretty hardcore equiptment to pick up a single data stream without the ability to wrap a pickup coil around a single wire. All it takes to pick up wireless network signals is a $30 card that comes preinstalled on laptops.
I've been telling people to use VPN over WiFi connections forever. Even better, put your wireless devices on the outside of the firewall, so they have no choice but to VPN in. This also makes giving a random guest access to your wireless no big deal. Any one who thinks wireless networking will ever be safer than an old-fashioned hub is deluding themselves.
Maybe people like me. My iPhone gets more reliable and faster service in my house than my Verizon DSL. I originally switched to AT&T from Verizon when I got my current job because I get no Verizon reception in my office. We are a really big company, so Verizon sent out a sales rep and two techs to make it better. They didn't get anywhere, people with Verizon phones still have to go outside to make a call (BTW, they get four bars right outside the door).
I ended up with an iPhone because AT&T didn't have any other good smart phones at the time, and I like AT&T's service. I didn't choose AT&T to get an iPhone.
My last two in-dash navigation systems have been twist-polarized. When I tilt my head, the diagonal black lines move.
SQL only runs as SYSTEM if you change the service account settings during install (in other words, not by default). Shell commands are not available unless the server is specifically configured for them using the "Surface Area Configuration Tool". Running as SYSTEM by default was fixed fourteen years ago and xp_cmdshell was disabled by default five years ago.
IIS improved seven years ago, not recently. Regardless of the reason for improvement, it did improve. IIS 6 and 7 both have excellent security records and both have a sound architecture.
Microsoft's far from perfect, but you've been holding a grudge for fourteen years. Did they eat your children?
Many applications such as Oracle, Apache, Tomcat etc typically run as SYSTEM on windows, and as their own users on unix.
So, many cross platform applications have bad security defaults when installed on Windows, but good defaults when installed on unix. That sound more like a frame job than bad security on Microsoft's part. The Microsoft equivalents (SQL Server and IIS) are configured properly by default. I'll bet that like IIS, at least two of the three don't run user threads as SYSTEM.
But what's more likely -- the NIC configuration changed on its own, or a process ran into some bad data and has gone into an infinite loop?
I'm pretty sure he was talking about an IEC C13 or C15. The C15 is a true kettle cord, and it will plug into a computer, so a lot of people think it belongs there. Most computers actually take a C13, but the C15 exceeds its specifications and can be used in place of a C13.
Our electricity may not be sufficient to run a 3KW appliance, but at least we don't kill any where near as many of our citizens by electrocution. Our plugs are almost begging to be touched, yours are rubber coated halfway up, so in theory you can never touch a lead while it is live, yet yours is still many times more dangerous. I'll use the stove to boil my water.
BTW, we also fuse our branch circuits way back at the entrance to the home at 15 or 20 amps. You nutcases run mains current through the whole damn house. I still get 24KW for my whole house, I just can't use it at all one outlet.
Oh..... and no one has ever gone into a rage after stepping on a plug that someone left on the ground in the US. Those plugs you guys have are freakin' sharp and have a nasty tendency to fall pointy side up.
Confirmed here too. My variant is that people suddenly become unable to perform simple tasks in the presence of a computer. I had one guy (with 20 years experience in front of computers) call me because a Windows install wasn't going so well. He gave me the normal "it won't let me install it". I asked him to read me every word on the screen, after five minutes I gave up and told him I'd fix it when I was there tomorrow. When I got in, the screen had a message on it that read "No drives were found". It was the biggest sentence on the screen and had a warning icon next to it. I proceeded to fix the problem (hard drive power cable loose), but not before snapping a picture with my cell phone. I showed him the picture later and he said "That wasn't there when I looked at it".
In this case, I think the goal to to shift the pain of low resale value back to the manufacturer. This will give them a real incentive to innovate and remove the inventive to simply lie to customers and tell them that the resale value will be just fine.
All the thing you mentioned leasing would do, we do today with propane tanks, but we don't lease them.
What? I'm not talking about someone substituting a value in a query with another (legal) value. I'm talking about people trying to insert clauses etc. Random ad-hoc SQL is heavily discouraged
Straw man argument. Stupid code is stupid. Stored procedures don't magically fix stupid code. I inherited a system where your exact example is done with a stored procedure. The idiots I took over from actually have a parameter in a stored procedure named @where_clause. It does exactly what it sounds like it does. So, the solution is actually code review and turning your brain on, not using stored procedures. Just because you happen to write good code by using stored procedures doesn't mean that using stored procedures contributed in any way to your writing good code.
By your logic, I could claim that stored procedures are a bad idea because they can be used to create dynamic SQL atrocities.
First of all, you've got some balls, which I admire, but you're too stupid to know when to shut up and you've needlessly crossed the line with me with this comment.
That was made with as assumption that you were like the previous ten thousand DBAs I've had this discussion with. Sorry if it was improperly directed at you, but it does apply to a lot of the readers of slashdot.
.Net application profiler is a thousand times better.
Back to my point. I've never claimed that going the "all data access goes through stored procedures" philosophy won't work. Your experience shows that it does. My claim is that it isn't the only way to skin this cat. Not using stored procedures has, for me, produced a more maintainable result. Everything you claim you get as a benefit from stored procedures, I also have in my data access layer. If two thing exhibit the same property, then that property is not unique to either of those things. Therefore, none of your positive experiences are reasons to choose stored procedures, unless those experiences aren't universal across all common solutions. For example, if you claimed that you must drive a Corvette to go 0-60 in under 5 seconds, you'd be wrong. All the evidence that a Corvette goes 0-60 in under 5 seconds wouldn't make you right. One shred of evidience that there is another way to go 0-60 in under 5 seconds proves the original statement false. I have evidence that all of those benefits that are enjoyed by stored procedure fans are also enjoyed by those employing a distinct non-SP data access layer.
Our discussion really boils down to two sides; your side claims that stored procedures are the only way to do it right, my side claims that there are many ways to do it right. I can't see how anyone could ever claim that there is no other way to do what they do. You'd have to have knowledge of every technology to make that claim.
Every claim you make, from control to logging, to performance tuning, to identifying issues and talking to those responsible to fix them, I can do. Only, I can do them better because I have better tools. Sure, sp_help2 works, but a
I also like the handwaiving of the BLOB issue. Since you don't have a technical argument (because T-SQL is literally not equipped to solve the problem), you simply suggest that it isn't a data-layer issue. I could change the argument to something like custom encryption, but I refuse to make the same point twice. I'll take the dodge as a win in my column unless you address it.
Step back and let the DBA's do their job. That means egress / ingress over all apps which want to use the DB.
Unfortunately, that means that a significant portion of the business logic will end up in the database. Since the middle tier is now embedded in the database, it is impossible to ever create a three tier application.
I have 15 years experience with Microsoft SQL Server, and I have trained half of the DBAs in my geographic area (seriously, I have). Please don't talk to me like only a DBA could ever build a data access layer that works. It is perfectly valid to build a data access layer that happens to live one step physically removed from the database. It is still distinct from the application, so there is no risk of a lack of abstraction, only it exists somewhere other than in stored procedures. T-SQL is an old language. There are at least twenty languages that can do many tasks better than T-SQL. I can do just about anything in my data access layer, and much of it is impossible with stored procedures. As an example... if I had a system that stored sensitive pictures in a database as BLOBs, and my requirement changed so that all returned pictures should be watermarked so we could track any information leaks. I could simply go into my C# data access layer and add a handful of lines of code that would dynamically watermark the image as it is being retreived from the database. A data access layer written in T-SQL could never do this. T-SQL is a weak language.
Forcing stored procedures has costs. Modern technologies like LINQ to SQL don't work. Old curmudgeonly people known as DBAs constantly force you to restate all of your requirements and then say no to half of them because they don't have the talent to pull it off. Applications break after a change because it is assumed that the DBA knows who is calling a stored procedure, but that is a pure fallicy that can only be handled by manual documentation - the sort of documentation that us application developers are also good at (my development tool can do a dependency analysis with the click of a button).
Our old stored procedure based development architecture is fragile and breaks all the time on changes because it is so complicated to figure out what is being accessed. Our new non-stored procedure based architecture has been rock solid for five years and many updates. I'm not saying that stored procedures caused the problems in the old architecture, but I am saying that stored procedures were not sufficient to prevent data layer fragility. You are using the worst possible argument for stored procedures, "DBAs are smart and developers are stupid".
There is no way you will create more efficient DB code than a competent DBA, and you should not have to worry about the hinting / indexes / partitioned views etc that DBA's consider when making sure your stuff runs well.
The two cannot work in isolation. How would you create a covering index if a developer demanded all columns of a table be returned, but he didn't really need them? How do you performance tune an application that requests the details for 10,000 customers by calling the customer profile retreival procedure 10 thousand times? Unless everybody participates, it won't work well.
I hope you're not trying to tell me your DBA trusts your app writers to sanitize everything?
They better. Procedure calls are just as vulnerable to SQL injection as ad-hoc SQL. The only person is a position to stop SQL injection is the application developer. The damage has been done before the DBA's code is even called.
... the DBA loses control ...
That is your real fear. You simply want to be involved in every project to jusify your existence and refuse to admit that there is any other way to write applications, because those other ways reduce your value to the organization. I understa
You too need a demonstration. BTW, I don't need stored procedures to handle permissions because all of my applications are three tier and frond end users can't even log in to the database server.