Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Vexamus
Starting Member
1 Post |
 Posted - 2011-09-22 : 05:43:55
|
| So I'm the CIO of a tech company, we sell an application that currently is developed with the Clarion development tools and uses TopSpeed (TPS) flat files for it's database. To me, this is all fine and great since the app was developed originally many many years ago as a single system application (on premises to our customer)Now my boss has this "cloud" thing in his head and wants to provide the application as a managed service. Again, all fine, I have gobs of experience in virtualization and managed apps. Problem is that he's using the same logical structure as before...Layout: Terminal Server Farm across 20 VM's, unified storage system (iSCSI SAN), and Active Directory for user control. We have a handful of clients on each VM and they access their data in a share via the TPS ODBC driver. All the client databases are completely separate. Additionally, each table get it's own TPS file, there's nothing unified about the structure. So in my environment I have about 200 clients all with their own database sharing a single storage system.My boss swears up and down that "well I've been in this business for 25 years I've got x-amount of money invested in Clarion and we're never going to go to SQL because it's not fault tolerant and it generally sucks, I don't know why but that's just the way it is, etc, etc, etc." However, TPS doesn't scale for what he wants to do with his app. I'm generally able to make whatever call I need to that's in the best interest of our clients, however he seems to be hard pressed on this misinformation about SQL that he won't budge at all. It's extremely frustrating especially when he starts talking about adding an addition 1000 user to our system (we currently support about 1000 now and performance is suffering because of it.) I've tried convincing him that the architecture does not scale and we're going to end up upsetting all of our customers because of it. He doesn't want to hear it. He claims to know all of this stuff from experience yet he's never been on SQL. It's so very frustrating because evidence of his ignorance is abundant but it's like a pride thing or something, I have no idea. Either way it's going to bite my company in the butt if I don't convince him. Additionally, from what I've read it isn't difficult at all to transition our application from TPS to SQL, there are even companies that will do it for us.Is there anyone here familiar with the main differences between TPS and SQL in terms of high availability scaling that I can regurgitate and toss on my bosses desk? I need ammunition...Thanks. |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2011-09-22 : 06:12:33
|
Have a look at this case study for MySpace.com Then have a look at other case studies by industry (from the industry menu at the top).You'll find plenty of ammo.Like many business executives, your boss fears change. "It works now" is good enough for many decision makers, who (often rightly) feel that a bird in the hand... |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2011-09-22 : 06:44:57
|
"from what I've read it isn't difficult at all to transition our application from TPS to SQL, there are even companies that will do it for us."I know zero about Clarion and TopSpeed, but I came to SQL Server from an ISAM environment (15 years ago, or so). We took advice from the best IT brains our clients had (we are tiny, they were humongous).As an aside I asked the question (because Clients wanted "Open Systems") "What do you mean by open systems" and one of the clients' IT bods said "That's easy, its a proprietary system we buy from Oracle"  The best advice I got, which I didn't take, was to "rewrite the system completely"We faked the way that our old ISAM system used to work. The performance in SQL was "good enough". Unfortunately bits of it that were fine on Sybase, MS SQL, Watcom et al were dire on Oracle. We had things like "NEXT RECORD" which was easy to code in ISAM to step through the records. We converted that to SELECT xxx FROM MyTable WHERE MyPrimaryKey > @CurrentPKand we read the first record and then threw away the recordset. There is an equivalent of a LIMIT statement in Oracle, and a SELECT TOP 1 in SQL (didn't exist 15 years ago) that would have helped, but we didn't have the knowledge of SQL at the time to fix that sort of stuff, and we lots of code to change when improvements like that were discovered ...Basically, when we migrated the ISAM structure to SQL Server / relational database the logic in our application was no longer fit-for-purpose.Wind forwards several years and we had built Stored Procedures for every application-action. We can adjust / tune / refactor a stored procedure without having to modify the Application code. We can tune the indexes out-with the application.It may be that your application has some layers of abstraction between the APP and Top Speed, or that Clarion can use a SQL backend as an alternative to Top Speed (in an efficient manner, with negligable code changes), but I would take whatever numbers you have and multiple by at least 100  All your DEVs are going to have to think "set based". Coming from ISAM that took me at least a couple or years (because I couldn't down-tools for months to learn the new environment, we had to generate income and migrate in a low-risk manner - so small-changes-steps rather than quantum-leaps)Maybe you can make the change in a smarter way than we did, or employ some smart consultants to help you (we did that, the guy was brilliant, but I still talked him out of some of the more major things he wanted us to do; dunno if we should have done them, we did migrate with low risk as per my wish, and had very little client-end failures, but it took us years, and numerous step-releases, before we had a truly relational database application so ultimately the DEV part was very expen$ive)But SQL Server is the mutt's-nuts so you'll be glad once you have got there |
|
|
|
|
|
|
|
|
TPS vs SQL help...