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.
That's becouse they where used as developer toys instead of parts of the data store. Take any application thats maintained by sloppy developers over several years all working together, and the same thing tends to happen..
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.
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. I don't want to have to worry if Joe Slickback next to me knows how to properly setup his tables. Also, hiding access to tables and allowing access to the procedures allows your data's 'Master' to protect the data it serves.
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.
BINGO! But the problem is, saying that stored procedures can cause this pasta mess is silly. Anyone who could end up in that situation are going to, chances are, have all their crap mixed together, jumpled, undocumented, and generally held together with digital bubblegum.
That's the largest arguement I've had.. If you have the people to maintain the database, then engineers can do the fun stuff, like, write code. If not, they have to write code AND maintain data..
In a way, you sort of give good reasons to USE stored procedures instead of against..
Untimatly, it depends on the size of a database, etc..
In a case where, lets say, your doing credit card processing. The database will be large, intensive, and cetralized for a company whos primary buisness is to process credit cards.
And in that case, you have full time DBAs who know what the hell they are doing, and can tke on the full time responsibility to monitor and maintain the data..
It depends on the development approach. If you have alot of data, and limited things to DO with the data, then they make sense..
If not, then your developers are maintaining the data, and hence, stored prox are a bad idea..
It all depends on your environment, really, and whos managing the data, the engineers, or the DBAs..
And.. You have first hand experience in modifying the trajectory of large objects hurling thru space? Over millions of miles, a small nudge can move any objects possibly enough..
Having select access on a tables containing screen names is something that even a customer service app. Generally, IF they where stored in something that would be searching by screenname, etc, you wouldnt want to be having it search thru actual account information for the screen names.
In many cases, they kernel itself calls code into the drivers, so when the drivers go boom, they can take kernel threads with them..
A good example of this is with Win2k Advanced server. At one point, we had code that under NT would PURPOSLY call a Dr Watson that customers could turn on when the application crashed. Basically, you turned it on, and it used the atexit() to make a call into our stuff, and there we'd promptly assign NULL to a value, automagically causing Dr watson to kick in and give us some trace data.
Under Win2k Advanced server, the atexit was handle, BY THE KERNEL. When it did this under that OS, it'd blue screen.
The data will be found. Exactly as your example. Everquest. It still has the same old issues, if not worse, in that now it can all be wrapped up in the easy to use 'Macroquest', which, ironically enough, doesn't sniff packets, it attaches and reads the memory..
But what I'm saying is, should we say they are LEGALLY responsible to do so, if indeed, as the post said, the players 'own' their stuff, just like real life..
If you hold that it's ANY more then that, then whats to stop lawsuits to say, keep Everquest around after Sony decides it's no longer profitable? Where is the line drawn?
Inside of an XML document, you can designate the 'rules' governing the XML format. Inline DTDs and the such. It's a moot point, as I have yet too see a jabber client or server implement it, most specifically becouse you cant really validate an XML stream without some sort of hack of wrapping up the snippeets as an entire document.
True, the decyption of sort isnt trivial, but it only has to be written ONCE. And with the fact that the protocol has to be documented in order to be used. Well, the hard part's done..;-)
In all of your cases, you are correct. However, name one open net standard that uses a binary protocol for communication, when the data isn't inherintly binary in the first place, such as transfering binary files. Yes, the binary information can bee a snapshot of a 'C' structure, however, this makes it extremely difficult to improve the core protocol used AND provide backwwards compatibility. In addition, this makes platform and languagee portability a huge pain in the ass.
Your points make NO sense. Makes it harder to reconcile? In general, two way conversations ALWAYS have the sent and recieved sides. Unless you have some sort of new ESP protocol, to sense something in a different way.. Umm.. I suppose I just dont get what your statement means in english.. As far as not scaling to 3 or more way conversations, it isnt possible to do it any other way on the net without using multicast of some sort. You can't open a single port to multiple computers.. Get a clue..
As far as your third, it's pretty much required to use a SAX based parser for XMPP, unless you wrap it. If the session ends premeturely, yeppers, you have an invalid XML document. But theen, most of the time, SAX parsers dont validate the XML.
Chances are, this appliance is probrably a proxy of some sort. AOL gives out an IP address, and the box itself probrably either proxies for the box itself, and logs it all, or some sort of redict is sent out so the box can record all traffic.
Using this method, they could also do an automated trace on the line, if he was using dialin, which I'd imagine, if he was smart, he was..
I could just as easily post an article saying 'Get *4* Tires, *2* axells, and engine, and a few other things. Toss them all together, and you just made your own CAR!!'
I mean cripes. It's not talking about ANYTHING besides 'buy cheap puters and put neat graphics up'.
I've had bosses that could have written this article.. Heck, I bet they did. 'Whatcha wantt a fluke for? I mean, we BUILT you a NOC for a grand!!' Bear in mind, the 'NOC' was a closet with two monitors I salvaged..
I dunno, perhaps I'm just getting old but..
I fee like I just wastes a good minute of my life reading that..
Slashdot Mirror
You mean, like AIM already DOES?
AOL does indeed do something simular to this, no lie. But the ad companies use and read cookies that are placed by AIM itself..
Another location too see amazing Pov-Ray images is http://www.irtc.org
Alot of the hall of fame images are actually winners of that ongoing competition
That's becouse they where used as developer toys instead of parts of the data store. Take any application thats maintained by sloppy developers over several years all working together, and the same thing tends to happen..
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. I don't want to have to worry if Joe Slickback next to me knows how to properly setup his tables. Also, hiding access to tables and allowing access to the procedures allows your data's 'Master' to protect the data it serves.
BINGO! But the problem is, saying that stored procedures can cause this pasta mess is silly. Anyone who could end up in that situation are going to, chances are, have all their crap mixed together, jumpled, undocumented, and generally held together with digital bubblegum.
Spoken from the mouth of someone who doesnt have a clue..
WHY isnt it as easy to add more database servers then it is to add more web servers?
It's becouse you're not looking at the applications from the side of someone who manages data and databases.
It can work both ways. And in reality, it should work both ways..
Ever seen a database having rows locked by 100 different web servers becouse they DIDN'T use any form of stored procedures?
EXACTLY.. ;-)
That's the largest arguement I've had.. If you have the people to maintain the database, then engineers can do the fun stuff, like, write code. If not, they have to write code AND maintain data..
It depends on what you have for a team..
In a way, you sort of give good reasons to USE stored procedures instead of against..
Untimatly, it depends on the size of a database, etc..
In a case where, lets say, your doing credit card processing. The database will be large, intensive, and cetralized for a company whos primary buisness is to process credit cards.
And in that case, you have full time DBAs who know what the hell they are doing, and can tke on the full time responsibility to monitor and maintain the data..
It depends on the development approach. If you have alot of data, and limited things to DO with the data, then they make sense..
If not, then your developers are maintaining the data, and hence, stored prox are a bad idea..
It all depends on your environment, really, and whos managing the data, the engineers, or the DBAs..
And.. You have first hand experience in modifying the trajectory of large objects hurling thru space? Over millions of miles, a small nudge can move any objects possibly enough..
As a software Engineer?
God damned it, NOW I know where all those web monkeys from the dot com boom went!
Guy. Read..
He was a farging software engineer.
You know, the kind of people that write in the safeguards?
Too get screennames?
Having select access on a tables containing screen names is something that even a customer service app. Generally, IF they where stored in something that would be searching by screenname, etc, you wouldnt want to be having it search thru actual account information for the screen names.
Hehe, no. I'm saying that by his/her logic, you can't be a critic of a film if you haven't made your own..
My Karma has ben in tact for years now, with a user ID near 1000..
Interesting concept..
So, basically, you can ONLY critisize something if you managed to rip the idea and make your own..
Ever written an OS?
Wait. Have you ever written an automated bot to post slashdot comments? If no, then you must STFU, as you have not done it yourself..
Shesh..
Why does that sound like EXACTLY something that would have been SAID on Southpark..
"I hate that TV thing."
"Yea, it sucks.."
"Yea, lets go find something better to do.."
*blink*
For all the spouting, you missed what was said. *10 years ago*, it was a toy..
In many cases, they kernel itself calls code into the drivers, so when the drivers go boom, they can take kernel threads with them..
A good example of this is with Win2k Advanced server. At one point, we had code that under NT would PURPOSLY call a Dr Watson that customers could turn on when the application crashed. Basically, you turned it on, and it used the atexit() to make a call into our stuff, and there we'd promptly assign NULL to a value, automagically causing Dr watson to kick in and give us some trace data.
Under Win2k Advanced server, the atexit was handle, BY THE KERNEL. When it did this under that OS, it'd blue screen.
Just an example..
The data will be found. Exactly as your example. Everquest. It still has the same old issues, if not worse, in that now it can all be wrapped up in the easy to use 'Macroquest', which, ironically enough, doesn't sniff packets, it attaches and reads the memory..
But what I'm saying is, should we say they are LEGALLY responsible to do so, if indeed, as the post said, the players 'own' their stuff, just like real life..
But, then again..
It's a game..
If you hold that it's ANY more then that, then whats to stop lawsuits to say, keep Everquest around after Sony decides it's no longer profitable? Where is the line drawn?
Inside of an XML document, you can designate the 'rules' governing the XML format. Inline DTDs and the such. It's a moot point, as I have yet too see a jabber client or server implement it, most specifically becouse you cant really validate an XML stream without some sort of hack of wrapping up the snippeets as an entire document.
But that's an argument about XML, and not XMPP.
True, the decyption of sort isnt trivial, but it only has to be written ONCE. And with the fact that the protocol has to be documented in order to be used. Well, the hard part's done.. ;-)
In all of your cases, you are correct. However, name one open net standard that uses a binary protocol for communication, when the data isn't inherintly binary in the first place, such as transfering binary files. Yes, the binary information can bee a snapshot of a 'C' structure, however, this makes it extremely difficult to improve the core protocol used AND provide backwwards compatibility. In addition, this makes platform and languagee portability a huge pain in the ass.
Your points make NO sense. Makes it harder to reconcile? In general, two way conversations ALWAYS have the sent and recieved sides. Unless you have some sort of new ESP protocol, to sense something in a different way.. Umm.. I suppose I just dont get what your statement means in english.. As far as not scaling to 3 or more way conversations, it isnt possible to do it any other way on the net without using multicast of some sort. You can't open a single port to multiple computers.. Get a clue..
As far as your third, it's pretty much required to use a SAX based parser for XMPP, unless you wrap it. If the session ends premeturely, yeppers, you have an invalid XML document. But theen, most of the time, SAX parsers dont validate the XML.
Chances are, this appliance is probrably a proxy of some sort. AOL gives out an IP address, and the box itself probrably either proxies for the box itself, and logs it all, or some sort of redict is sent out so the box can record all traffic.
Using this method, they could also do an automated trace on the line, if he was using dialin, which I'd imagine, if he was smart, he was..
What I would't do for some moderator points about now...
*lololololololololol*
This article was a complete waste of time..
I could just as easily post an article saying 'Get *4* Tires, *2* axells, and engine, and a few other things. Toss them all together, and you just made your own CAR!!'
I mean cripes. It's not talking about ANYTHING besides 'buy cheap puters and put neat graphics up'.
I've had bosses that could have written this article.. Heck, I bet they did. 'Whatcha wantt a fluke for? I mean, we BUILT you a NOC for a grand!!' Bear in mind, the 'NOC' was a closet with two monitors I salvaged..
I dunno, perhaps I'm just getting old but..
I fee like I just wastes a good minute of my life reading that..