Salakhetdinov Shamil
mcp2004 at mail.ru
Thu Nov 17 14:34:40 CST 2011
John -- Well, you use SQL backend mainly as a "dumb" relational engine, no (advanced) server side static T-SQL Stored Procedures, no T-SQL User Defined Functions simulating "virtual" tables?.... And quite a few of custom client side metadata driven C# coding to build dynamic SQL, advanced custom UI framework etc.? Then your transition to mySQL: should be probably rather smooth... But if you use MS SQL/ .NET SQLBulkLoad classes then you might need to substitute them with custom coding ... I do it different way when using MS SQL: I'm trying to keep as much as possible business rules and logic on server side implemented in Stored Procedures, User Defined Functions, Views etc. By doing it that way I can keep my client side layer as thin and as dumb as possible, and my C# business layer not overloaded with custom "plumbing" etc. Advantages: clear "separations of concerns" of different application system layers, streamlined coding, relatively low support and functionality extensions costs, possibility to have all kinds of modern UIs using the same core business and data layers, as MS software supports all the modern UI-development technologies ... Disadvantages: I'm "bound" to MS SQL back-end... But nor I nor my customers do not care about that binding as it doesn't limit any way our freedom to support and to extend current solutions, and my customers do not yet have that much data to not fit one MS SQL Express database, even customer with more than 8000 users of an ASP.NET web site running for four years without any serious issues ... When my customers will need more processing power then we will probably move to a hosting site/cloud.... If you can split your databases into many smaller databases then you can also put them on hosting sites and "wrap" by web services still running using MS Windows, and then make your application consolidating that data - I guess it wouldn't be needed to get gigabytes of data retrieved to your client layer during such consolidation?... Thank you. -- Shamil 17 ноября 2011, 23:11 от jwcolby <jwcolby at colbyconsulting.com>: > Shamil, > > OK, so now that we understand that it is in fact a client's new server that I was discussing > originally, let's go ahead and discuss doing the same thing here at my home office. > > First take a look at this article: > > http://dev.mysql.com/tech-resources/articles/move_from_microsoft_SQL_Server.html > > It would appear that I could in fact run MySQL right on my existing server should I so desire. > > I have built my mongo server around Windows 2008 and SQL Server 2008. I have written a custom C# > application which performs massive table updates every month. Due to the fact that the server runs > an X64 version of windows and I installed an X64 version of Visual Studio on the server, and the > fact that the X64 version does not support "edit and continue", I actually run the C# application on > vmDev which runs an X32 version of Visual Studio. > > The application runs on a VM and the actual database manipulations run on the X64 server. The > application, written in C#, executes dynamic SQL on the server, getting back results. > > If I needed to, what would be the "costs" to move to MySQL? The question becomes: > > 1) Cost to install and come up to speed on MySQL. > 2) The complexity (time) to move the data from SQL Server to MSSql. > 3) What is involved in porting the code to use dynamic SQL that MySQL supports? > > In my case the databases I manipulate are not very complex. Typically each database has two or a > few tables. I am not using stored procedures in SQL Server, in fact I have intentionally migrated > away from doing so (I used to). My "stored procedures" are now C# routines and dynamic SQL. I find > C# much more flexible as a language and find no need for stored procedures *for this application*. > > My take on migrating this application to MySQL is that I would not hesitate to do so if I needed to, > and I do not currently need to. I do not need to run the C# code itself on the server so even if > the database or MySQL were hosted on Linux, I could still probably run my application, assuming the > Dynamic SQL port. > > After the migration, the TCO seems to be similar, or perhaps lower than an MS only solution since > SQL Server licensing costs go away. If I were to migrate to Linux then Windows licensing costs go > away. These are not insubstantial costs. I do not use Linux or MySQL so I cannot speak with > authority but they both appear to have reached the point where they are not rocket science, or any > more so that maintaining Windows server software is. > > I am really exploring this more in the context of future business. MS licensing is already so > convoluted and costly that small businesses are protesting server based systems. They used to use > Access and I used to recommend Access, be and fe, but am I going to continue doing so? I think not. > > So what do I recommend when MS wants $10K to $20K for the Windows / SQL Server licenses for a new > server? For the small businesses I work for this is a large chunk of change. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 11/17/2011 9:34 AM, Salakhetdinov Shamil wrote: > > Hi Hans, Jim, John, Darryl at all -- > > > > Sorry I didn't reply promptly on your postings here - I have had to release a solution to my customer... > > > > I do not state that mySQL or Linux are not worth to consider - that would sound really silly. > > I'm just trying to keep to discuss this thread practical case when JC's is going to "jump at" mySQL after three years(?) of building his mighty computing environment with MS SQL being the core of it AFAIU. > > > > How much time it will take for JC to setup the new environment? > > How much time the transition of JC's large database will take? > > Will existing code work "automagically" with the new backend? > > Aren't there other ways to use MS SQL on multi-core servers having just one core used for MS SQL and others for custom (code) data processing? > > What "hidden side-effects" JC is going to meet during transition? > > Who will pay (the bills) for that transition? > > .... etc ... > > > > IOW there is no any "red herring" coming from here IMO. > > > > You know I'm not anymore that excited about learning new and new technologies as hobby - I'm much more excited about "getting things done" and my bills paid in time. > > > > I agree with Jim that these are interesting times our (custom) software development industry is entering nowadays - maybe even more interesting and exciting than 80-ies and 90-ies - but I'd disagree that without knowing Linux and mySQL and being "pure MS shop" one takes themselves at risk of getting out of market (let's not discuss that my point of view here as it could become OT with all the parties keeping their point of views unchanged....) - after all MS development tools cover/support most of the modern widely used desktop and web development technologies and web/cloud hosting costs are comparable for Windows and Linux and there are a lot of open source software and information for "MS-tied" developers... > > > > Hans you noted: > > > > <<<<<<<<<<< > > But, in my opinion, more often than not, there are 3 essential reasons why people use the product they have: > > > > 1. They really need a certain feature > > > > 2. They are required to use that product (by a third party) > > > > 3. Or simply that they feel most comfortable using said product. > >>>>>>>>>>> > > > > I agree but for JC real life case all the three above positions seems to be questionable IMO. > > > > As Darryl writes: > > > > <<<< > > In reality we use a whole stack of software tools, From Excel, Access, SQL Server Express to dedicated mining software with GemcomWhittle and Surpac. The plan was not so much to replace SQL Server Express, but replace it for this job and see how it works. If MySQL has the grunt and space to get a result then I will use it this time. It may not be the best tool for next time. We really do use the best tool for the dataset we have. Sometimes that is Excel, although it usually is Access > >>>>> > > I agree of course but again for JC certain case IMO "hurrying to jump at mySQL backend" without trying to evaluate other alternatives while "staying at MS field" sounds questionable here. > > > > I can be wrong, life and JC practice will (soon) show was that worth to abandon MS SQL for ***one of his projects*** of not. > > > > Sorry John I'm referring your case - feel free to stop this discussion thread you started if you don't want to discuss it in this direction... > > I could have misunderstood your intentions and very probably you're just going to "test the waters" there with mySQL and if it will not be "deep" for you then you'll make the full well planned transition paid by your customer - I'd have done the same... but after I'd have found I can't keep using MS SQL for a certain project/customer as it becomes too expensive to be true... > > > > Thank you. > > > > -- Shamil > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >