Well I'm drunk right now but I wasn't when I posted. My point was simply that the most common example of providing database transparency to programmers would be an API, as I stated and I believe you are repeating.
If you want to explain to me the succinct meaning of "making the database transparent to programmers and customers" and/or how it might be such a trivial task as to be accomplished in only 30 different ways, please enlighten me. I mean, besides an API (there I go showing off again), what is dasMegabyte talking about? Up a step to wrapper functions or a class? How is that simple in the sense that 30 solutions would be a *large* number? Even then, how would that take care of the "customer transparency" part?
hmmm... database transparency to the customer... sounds suspiciously like web app marketing speak to me (unless it was a typo and he meant "consumer" as in consumer/provider in an unspecified technical sense, but customer and programmer sound very much like actual human beings). If you think it through you'll see what I mean. And if you read the flood of critical and argumentative replies, you'll see that plenty of other people's bullshit detectors went off as well - not just mine. I was perhaps a little more insulting, mean and childish in my response than others but, hey, it's cheaper than therapy.
By the way, did you say something about inventing KFC? Or was that "manager at KFC"? Either way, you guys make the best corn I've ever had. Don't let anyone tell you different.
And it's posts like yours that remind of the idiot monkey boys with CS degrees whose diapers I have to change every day, kind of like this guy: http://www.jedimaster.net/
" the relatively simple problem of how to make the database transparent both to customers and to programmers"
What are you even talking about?? Are you talking about an embedded database, some type of proprietary database format, or a database server? What do you mean by "transparent"? You could define an entire database frontend application (comprised of thousands of lines of code) as primarily serving to "make the database transparent". I wouldn't call that a "simple problem", I would call it a "project."
Making a database transparent to *programmers* would generally be called an "API" (I hope I'm not losing you with this advanced lingo) - and again may involve thousands of lines of code. Man, can I borrow that magic binder of yours sometime? Only 30 ways to any database frontend or API - you must be a friggin genius!
I also enjoy your comment about MS having "profit DOWN". Let me interpret that statement: "I am a shallow, greedy bastard so, naturally, I respect others who are even greedier than myself. It eases my guilty conscience and gives me something to dream about because I am a failure." It's like any anonymous loser making the brilliant observation that "Hitler had politics DOWN." The point is that, while your statement about MS is self-evident, it has nothing to do with the merits, logic or legality of their actions. It's a child's argument. You are a fool. Please stop programming transparent databases and get back together with your high-school rock band. Oh yeah, and smoke more pot.
PHP's builtin URL rewriting function does slow things down. That's one (but not the only) reason you should do it in the app itself. It's easy if you think about this *before* you start coding.
Here's a simple version of a function I use to write every URL in a site. This one would normally create fully qualified URL's but you don't have to. $m is for "module" (what many people might call "page" - e.g. "home", "signup", "cart") and this function is intended for use in a centralized-script architecture.
function makeUrl($m, $qryString='', $anchor='', $addSID=1) {// Create navigation URL.
$url = URL_ROOT . "index.php?m=$m";
if ($qryString) {
$url.= '&' . $qryString;
}
if ($addSID) {
if (defined("SID") && ($_COOKIE[session_name()] != session_id())) {
$url.= '&' . SID;
}
}
if ($anchor) {
$url.= '#' . $anchor;
}
return($url); }
The advantage to writing every single URL through your own function is that you can easily extend them later. For instance, the above function spits out regular dynamic URLS but can be trivially modified to support fake static URL's to be used in combination with Apache mod_rewrite.
Not if your site is designed properly. Take a typical ecommerce site for instance. First of all, use query string session id's only in non-critical areas of the site so that the most information a hijacker would see is the legitimate visitor's personalized content (e.g. your name, as in "Hello CryBaby, welcome back to BangkokLadyBoysForSale.com") and maybe the contents of their shopping cart.
Second, force visitors to re-enter their password when entering critical areas of the site (like account maintenance and checkout) and pass the session id forward through form fields via POST (over SSL of course), not URL's.
Third, remember to never pass any actual user information, like user id, pass etc., in URL's or form fields. Tie in user info based solely on the session id.
Fourth, you can pass a message authentication digest along with the session id to prevent random hijacking. I only find this useful in critical or sensitive areas of a site, but you could do it everywhere.
I design every site to use cookies when available but to support cookieless sessions otherwise. If done properly, there is ZERO reduced security but severely reduced customer service BS and increased sales/traffic. See amazon.com for an example of the above methods (Yeah, like any web programmer worth their salt, I basically copy Amazon).
Requiring cookies for proper functionality is no different than requiring JavaScript - sure sign of an amatuer coder. (OK, there are always exceptions, but I'm talking generally about "industrial-strength" public sites)
Slashdot Mirror
Well I'm drunk right now but I wasn't when I posted. My point was simply that the most common example of providing database transparency to programmers would be an API, as I stated and I believe you are repeating.
If you want to explain to me the succinct meaning of "making the database transparent to programmers and customers" and/or how it might be such a trivial task as to be accomplished in only 30 different ways, please enlighten me. I mean, besides an API (there I go showing off again), what is dasMegabyte talking about? Up a step to wrapper functions or a class? How is that simple in the sense that 30 solutions would be a *large* number? Even then, how would that take care of the "customer transparency" part?
hmmm... database transparency to the customer... sounds suspiciously like web app marketing speak to me (unless it was a typo and he meant "consumer" as in consumer/provider in an unspecified technical sense, but customer and programmer sound very much like actual human beings). If you think it through you'll see what I mean. And if you read the flood of critical and argumentative replies, you'll see that plenty of other people's bullshit detectors went off as well - not just mine. I was perhaps a little more insulting, mean and childish in my response than others but, hey, it's cheaper than therapy.
By the way, did you say something about inventing KFC? Or was that "manager at KFC"? Either way, you guys make the best corn I've ever had. Don't let anyone tell you different.
And it's posts like yours that remind of the idiot monkey boys with CS degrees whose diapers I have to change every day, kind of like this guy:
http://www.jedimaster.net/
Were you molested by a 512K Fat Mac as a child?
" the relatively simple problem of how to make the database transparent both to customers and to programmers"
What are you even talking about?? Are you talking about an embedded database, some type of proprietary database format, or a database server? What do you mean by "transparent"? You could define an entire database frontend application (comprised of thousands of lines of code) as primarily serving to "make the database transparent". I wouldn't call that a "simple problem", I would call it a "project."
Making a database transparent to *programmers* would generally be called an "API" (I hope I'm not losing you with this advanced lingo) - and again may involve thousands of lines of code. Man, can I borrow that magic binder of yours sometime? Only 30 ways to any database frontend or API - you must be a friggin genius!
I also enjoy your comment about MS having "profit DOWN". Let me interpret that statement: "I am a shallow, greedy bastard so, naturally, I respect others who are even greedier than myself. It eases my guilty conscience and gives me something to dream about because I am a failure." It's like any anonymous loser making the brilliant observation that "Hitler had politics DOWN." The point is that, while your statement about MS is self-evident, it has nothing to do with the merits, logic or legality of their actions. It's a child's argument. You are a fool. Please stop programming transparent databases and get back together with your high-school rock band. Oh yeah, and smoke more pot.
PHP's builtin URL rewriting function does slow things down. That's one (but not the only) reason you should do it in the app itself. It's easy if you think about this *before* you start coding.
// Create navigation URL. .= '&' . $qryString; .= '&' . SID; .= '#' . $anchor;
Here's a simple version of a function I use to write every URL in a site. This one would normally create fully qualified URL's but you don't have to. $m is for "module" (what many people might call "page" - e.g. "home", "signup", "cart") and this function is intended for use in a centralized-script architecture.
function makeUrl($m, $qryString='', $anchor='', $addSID=1)
{
$url = URL_ROOT . "index.php?m=$m";
if ($qryString) {
$url
}
if ($addSID) {
if (defined("SID") && ($_COOKIE[session_name()] != session_id())) {
$url
}
}
if ($anchor) {
$url
}
return($url);
}
The advantage to writing every single URL through your own function is that you can easily extend them later. For instance, the above function spits out regular dynamic URLS but can be trivially modified to support fake static URL's to be used in combination with Apache mod_rewrite.
Not if your site is designed properly. Take a typical ecommerce site for instance. First of all, use query string session id's only in non-critical areas of the site so that the most information a hijacker would see is the legitimate visitor's personalized content (e.g. your name, as in "Hello CryBaby, welcome back to BangkokLadyBoysForSale.com") and maybe the contents of their shopping cart. Second, force visitors to re-enter their password when entering critical areas of the site (like account maintenance and checkout) and pass the session id forward through form fields via POST (over SSL of course), not URL's. Third, remember to never pass any actual user information, like user id, pass etc., in URL's or form fields. Tie in user info based solely on the session id. Fourth, you can pass a message authentication digest along with the session id to prevent random hijacking. I only find this useful in critical or sensitive areas of a site, but you could do it everywhere. I design every site to use cookies when available but to support cookieless sessions otherwise. If done properly, there is ZERO reduced security but severely reduced customer service BS and increased sales/traffic. See amazon.com for an example of the above methods (Yeah, like any web programmer worth their salt, I basically copy Amazon). Requiring cookies for proper functionality is no different than requiring JavaScript - sure sign of an amatuer coder. (OK, there are always exceptions, but I'm talking generally about "industrial-strength" public sites)