>> Comments about failed projects based on differing technologies. >> Comments on speed of that vs speed of this.
>> Comments saying this thing bites and this other thing is... Whoa - slow down... I don't hold a PHD in database design but I do know: 1) A project fails for many more reasons than the database it was built upon. If CHCS II failed, VistA failed/fails, or "This new thang" fails - it has many factors involved. CHCS II could be "slow" because the developers queried the database wrong, designed the database wrong, forgot a crucial clustered index on 2 level join and returned unused columns thru an uncached web service. Whatever the reasoning - computers do what they are told and they're usually told wrong. 2) An effective system is more than the benchmark. If you have a bug turn-around time of 2 days instead of 2 weeks because the system is "better" but takes 20% longer to return your report - is it worth it? What if you could build a new feature in 1/4 the time because the system is modular, etc? What if your bug count was much lower because you utilized test-driven development, unit testing, etc? Where's the line between productivity and speed? I could write an ISAPI filter for IIS that'll return pages REALLY FAST because it was written in C but it won't be easily maintained or flexible. 3) Any project directly ported to another technology will not benefit from the advances in that new technology. If I had, say the Windows or Linux Kernel written in C. Porting it to some new technology like E (D actually exists) - will it simply work faster? Probably not. Not because E is a bad language, the kernels simply take advantage of C as it was implemented. The same thing applies to databases. My current SQL Server and OLAP (Analysis) Server are not the same. Two technologies used for different purposes. M is different, no doubt about that. But if you were to build a business application that once read lines out of a text file, would you have a relational database consisting of a single table and one column that holds each line of the text file? Nope. You'd probably normalize that thing out and make the most use of your technology. Maybe mapping VistA straight from M -> SQL isn't the best approach? If it is or isn't, I don't think one organization's implementation of an EMR sets the pace for comparison. Epic uses SQL - not all banks use M - many CRMs use relational system - etc. Going back to #1 - it's not just the database's fault. 4) Dropping VistA for the sake of changing technologies. I have a saying (well, I never actually say it out loud) - change platforms when your current platform restricts your architecture options. If SOA (web services) is something you want and you can't do it in ASM - then you should check your options. There are many languages out there and they're all good at something - but not everything. Could VistA be re-written in .NET, Java, or Python? Yes. Can it be just as successful as VistA-M? Possible. Depends on the interface between the chair and keyboard. And may I recommend this: http://www.amazon.com/exec/obidos/tg/detail/-/0596100124/ref=wl_it_dp/00 2-5699553-5527248 Database in Depth by C.J. Date Remember: You can't optimally use the targeted system until you know how it works under the hood. If you're using .NET or Java, question those easy-to-use syntax commands. So why is the StringBuilder better than looping thru a string? Why is a string immutable? Why does a patient's meds take longer to load on the new system than the old? Check those queries, your data model, your middle/business tier, etc. And if it's truly new technology - are you using fetch-ahead, background/multi-threading, caching, etc. Out. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
