L' Eomot Inversé (10/21/2013)
I certainly don't like the article referenced, it seems to me that it is a heap of assertions for whose credence no basis is offered. Yes, scalability needs to be a factor in design and in architecture and in selection of technologies, to the extent that scalability is a requirement. But claiming that the use of databases is the one thing that prevents scalability of websites is just unvarnished rubbish; almost always the main cause of lack of scalability is bad design. Bad design such as, for example, using 16 byte binary string identifiers for everything, instead of whichever of 16 bit, 32 bit, and 64 bit integer values provides enough range (even 8 bit in rare cases). Conversion between natural key and these identifiers through look-up in the database should be done rarely, at most once per session for each one, with the results cached in session data, which should not be in the database - - and of course consideration should be given to simplifying the design by using natural keys, which are unlikely to cause any more overhead than the 16-byte monstrosities advocated in the article. Another example of bad design which Mr Ozar seems to believe is a consequence of having a database is that session data is held in the database, something which I have never had the misfortune to see. At least I've learnt something useful from the article: that one should never allow PHP to be used for a website (at least not if what Mr Ozar says it does can't be switched off). Why does Mr Ozar translate that into "never use a database for website"? I can see nothing in use of a database that mandates use of PHP. I've been in the IT business since long before there were any web servers; even in the 1960s we didn't go back to the platform's security database and revalidate the login for every command issued by a MAC user; neither did we ask the platform software to store the current context of each logged in user, instead of having the MAC application do it for itself; the distributed TP systems for which I contributed parts of the infrastructure back in the 70s didn't make the mistake of putting the session data in the database (IDMSX, not an RdBMS at that date) either. Perhaps Mr Ozar's belief is that web designers with access to a database always make mistakes that we already knew, half a century ago for MAC systems and at least 40 years ago for TP, should be avoided.
+1000. I just went through some real hooie on one of the apps designed before the current team started. One of the apps checks for the credentials of the user on ever screeen and every object touched. Some of the pull downs check for credentials for every item in the pull down. One click would generate a dozen calls to the same credential proc (and we have a LOT of credentials. It's one of the worst designs I've ever seen but not the only one I've seen like it. Of course, the outcry was "the database has a performance problem". It sure did... the problem was the application using it. ;-)
It'll become a problem in the future again because their "fix" was to cache the credentials. It's still making a dozen checks per object clicked. Time for the webserver to start taking the blame for crap code.
It's a real shame that they don't want to spend the time to fix the bloody root problem!!!
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs