Design Discussion (offtopic from Fav Petitions)

HonoredMule wrote: I'm pretty keen on prepared statements myself.  I'm of a mind that if the front-end team can't be trusted to systematically handle SQL safely, they're probably going to create even bigger security holes via arbitrary code execution, which can include SQL anyway--and the restrictions just increase the back-and-forth/red tape, slowing development.  But if I were working with a larger team on larger deployments (i.e. the front and back end teams are actually separate entities as opposed to the same person or team of 3 people), I'd disable non-stored-procedure queries on the back end too.

Heh, not worried about the front-end teams code; just like to be in the stituation where if the web servers security is breached you still can't affect much

Obviously, it depends on the situation. If its an internal or closed user group business app then direct SQL isn't such a problem.

HonoredMule wrote: What I do find curious is the constant polling of json_currentresources.asp.  That seems like a lot of unnecessary overhead for a server designed to handle 100,000 users, when you could just use javascript timers to maintain projected resource levels, and at least make the server polling less frequent.

Thefts, completing resource buildings, trades, attacks, spells etc all alter the resource levels and the client side doesn't really know anything about. Its an area we are keeping an eye on but it isn't currently causing any issue.

"Whom would you consider to be in control of the number of db queries per page request--the back-end team or the web-front coders?

I didn't mean that in an authoritative/responsibility sense, but rather "whose code actually defines the amount of db usage."  Without a middle tier, I would presume that means the front-end makes a lot of direct calls, but being limited to stored procedures puts the optimization/I/O control back in the db admins' hands.

"If you want to use a trigger, you've broken it already" and "If you need a cursor, you've already failed".

Spot on. :)

The best teams I've ever worked with have been small, like-minded people who are flexible enough not to dismiss ideas and technologies because they don't (personally) understand or work in those technologies, or because those technologies are "old".

So very true.  After this term in university ends, I will be taking my time finding a job, not only to have time to develop my pet project, but also to take my time finding a group of "small, like-minded people" with which to work.  I had such a position, and may return to it yet...but that crew was drifting further and further away from web development, where my passion lies...and their clientele was "a bit seedy" (mostly telemarketers).  But one of the first things I learned while there was that perl in the right hands can still be pretty freaking awesome.

Hi HM,

I was using I/O fairly loosely to mean an aggregate of all the important measurables regarding getting stuff into and out of the DB, including Stored Proc Execution time etc.

No, no middle Tier.  And we fundamentally believe that it is the back-end DB team who have final authority over anything and everything, and can change / countermand / force redesigns (or different designs) on anything the front-end people want to put together.

However, it helps that most of us have strengths in the SQL back end, and both ThunderClap and I share the same fairly rigorous views about SQL... all those classic old-school things like "If you want to use a trigger, you've broken it already" and "If you need a cursor, you've already failed".

Stored Procs for everything.  In fact, pretty much the entire logic of everything that happens in the game comes out of Stored Procs, and the front end pretty much exists to show the output.

Yes, I think you have the characterisation spot on. 

We have backgrounds in extremely high-volume transactional DBs, but we've also been in the commercial / business world enough to know that architecture considerations (and oftentimes the wishes of a tech team to use X or Y technology because it's "better") are often at the expense of rapid development, deployment, stability, flexibility, and more often than not, profit.

The best teams I've ever worked with have been small, like-minded people who are flexible enough not to dismiss ideas and technologies because they don't (personally) understand or work in those technologies, or because those technologies are "old". 

After many years of putting the "con" and the "insult" into "consulting", I've lost count of the number of very large companies I've worked in with vast development teams who have ultimately hamstrung themselves through a lack of understanding of business objectives & business necessities and a zombie-like devotion to "we must use Y, Y is new, Y is better, Y is faster, Y is cool", when X worked perfectly well and probably didn't actually need replacing. 

Through years of painful experience, I became (and still am) massively cynical about anyone who describes themselves as a "Business Analyst", "Systems Architect" or "Data Consultant" - except in very specific industries and applications.

Anyway, you'll start me ranting for hours, so I'll stop now

HonoredMule wrote: "Classic" asp, I'm guessing, scales better than more robust, business-logic-centric .NET stuff.  That or asp is more flexible for loose scripting.

Very much the latter.

Plus the fact that I'm also quite incredibly incompetent at almost any sort of front end stuff - which is the domain that ThunderClap roams in, as the beastmaster of a herd of scripts, functions and "cascading style sheets" (whatever they may be).  Javascripty-stuff makes me shiver, I still believe Ajax was the son of Telemon and I never bothered to learn anything about .NET.

I'm led to believe that moving stuff into .NET would actually give us a staggering reduction in server-side page render clock time, and so things (as they settle) will indeed start moving across to .NET, prioritised by the harder hits parts of the front end.

HonoredMule wrote: What I do find curious is the constant polling of json_currentresources.asp.  That seems like a lot of unnecessary overhead for a server designed to handle 100,000 users, when you could just use javascript timers to maintain projected resource levels, and at least make the server polling less frequent.

Not my bit of the code I'm afraid, so can't comment - though I can say for sure that the DB I/O is quite beautifully petite.


Edited by GM Stormcrow - 24 Mar 2010 at 16:37