Len, > Well, I don't have to trust you. The master database has to be exclusively > on SQL database, any other products like Imail that need data from, or need > duplciate data from, will get synced to that, trying to sync in both > directions is crazy.
So...you do agree with me that going back from Registry-->ODBC is unfeasible? Your initial "I don't have to trust you" is unnecessarily combative, then. IAAP, that's why I ask for your trust on API-specific matters. > that still splits the database between some it on Ipswitch/registry > and other bits on SQL. You didn't read my post correctly. In this second section, I am referring to the fact that most people who complain about SQL performance vs. Registry haven't even tried to tweak SQL, so they're not yet qualified to complain. Many people who jump on the Registry/SQL hybrid idea--which I still think is a good idea, that's why I'm proposing its productization!--usually haven't done their homework first with the existing tools. Tweaking includes smart indexing, hardware rightsizing, Winsock Direct--just as it would for *any* performance-critical database. Once they tweak it, queries could be many, many times faster. Still slower than the Registry? Yes. But groan-worthy? Maybe not in nearly as many cases. And if Ipswitch publicized a bunch of hints and optimized their client-side calls, most systems wouldn't need the hybrid system at all. There would still be some with a deal-killing need for it, but they would be in the minority, as opposed to the norm. > I didn't say it would be easy, but there has to be a central "customer > database" on SQL as the foundation, master database, and other apps get the > bits they need from there. Simply because SQL is a better general purpose > database technology than a registry database. Like I said, I have a proof-of-concept architecture that adheres to your specifications--with the *strong* caveat that a separate management interface would need to be built to preclude orphaning account settings. If anybody who has done their due diligence with SQL optimization is interested in this product, please let me know. I just don't want to go building it, only to find that people's performance is still bottlenecked by a non-optimized back-end database. Let's get that out of the way first. > I really can't imagine running 200k users out of the registry as a > database. (I remember at one point that MS admitting NT4 SAM pooped out at > 14K users.) I don't know what in my post prompted this comment, but you need to look at the archives. In a message that I posted about a year ago, I established that this old chestnut only relates to the NT SAM and has absolutely nothing to do with Imail. You yourself, in fact, referred to my little white paper as a "keeper." Guess you didn't follow your own advice! Anyway, I don't understand why you, who are promoting its use as a high-speed cache, would start attacking the Reg's fitness for this purpose! Nobody's arguing (I never have) that its query language is suitable for multivendor systems. But its performance is kickass...that's benchmarked and non-debatable...under server-level load. Throwing in, out of left field, doubts about its stability is just plain silly--do you really want to run your cache off something you think isn't stable? It's still the primary point of contact for Imail in that setup, and if it gets corrupt or what-have-you (you've offered no proof of this, though), how do you propose that Imail knows it's getting bad data and refetches from the main DB? Sandy Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
