August 19, 2013 at 12:34 pm
Steve Jones - SSC Editor (8/19/2013)
Miles Neale (8/19/2013)
Hi Steve,I was out last week and came late to the game but needed to add something. Not all apps are .net and not all databases are SQL Server. There is a class of web server that is low-end, highly visible, and moderately used. In this area we are finding that the growth of CMS systems like WordPress, Joomla, and Drupal is expanding quickly. These sites include a standard WAMP or LAMP stack running mssql as the database of choice and they are cheap and easy to use. Using the CMS the database is almost encapsulated from the developer as well as large component solutions are available.
You mean MySQL, not mssql, right? I know many systems like this use MySQL or PostgreSQL. I with they had an option to use SQL Server or a plug in data access layer. Conversely, it would be nice if some other software written on SQL Server worked with other platforms.
Typo, yes MySQL. Thank you!
I have wondered why there is not a SQL option or layer as well. Then the idea come that a SQL agnostic back-end still has to to insure that SQL injection is stopped in its tracks. If we write a SQL solution that uses parameter driven stored procedures, we limit the back-end to those databases that understand and will execute in kind. However it we write an ANSI SQL compliant data system using direct calls w/o Stored Procedures it would work across all ANSI compliant platforms but would be open to injection and other problems.
Have to give this a little more thought.
Not all gray hairs are Dinosaurs!
August 22, 2013 at 6:35 am
From Brent Ozar, the software license cost three times the hardware...
http://www.brentozar.com/archive/2013/08/load-testing-solid-state-drives-raid/
For our design, we ended up with:
•Dell PowerEdge R720 with 2 quad-core CPUs, 384GB memory – $10k
•16 Samsung 840 Pro 512GB SSDs – $8k
•Hardware total: under $20k
•SQL Server Enterprise Edition licensing for 8 cores – $56k
Kinda keeps things in perspective, doesn’t it? The hardware seems insanely overpowered until you look at how much licensing costs. At that point, why wouldn’t you buy this kind of hardware?
August 22, 2013 at 8:52 am
Miles Neale (8/19/2013)
Steve Jones - SSC Editor (8/19/2013)
Miles Neale (8/19/2013)
Hi Steve,I was out last week and came late to the game but needed to add something. Not all apps are .net and not all databases are SQL Server. There is a class of web server that is low-end, highly visible, and moderately used. In this area we are finding that the growth of CMS systems like WordPress, Joomla, and Drupal is expanding quickly. These sites include a standard WAMP or LAMP stack running mssql as the database of choice and they are cheap and easy to use. Using the CMS the database is almost encapsulated from the developer as well as large component solutions are available.
You mean MySQL, not mssql, right? I know many systems like this use MySQL or PostgreSQL. I with they had an option to use SQL Server or a plug in data access layer. Conversely, it would be nice if some other software written on SQL Server worked with other platforms.
Typo, yes MySQL. Thank you!
I have wondered why there is not a SQL option or layer as well. Then the idea come that a SQL agnostic back-end still has to to insure that SQL injection is stopped in its tracks. If we write a SQL solution that uses parameter driven stored procedures, we limit the back-end to those databases that understand and will execute in kind. However it we write an ANSI SQL compliant data system using direct calls w/o Stored Procedures it would work across all ANSI compliant platforms but would be open to injection and other problems.
Have to give this a little more thought.
TBH I cannot remember the last time someone thought of writing SQL statements that were so SQL compliant that they were cross-RDBMS compatible. Most places I have worked develop a RDBMS specific data access layer but some do so whilst ensuring that it takes business entities or data transfer objects (i.e. database neutral types) so that the data access layer/tier can be replaced whilst the remaining parts of the application can remain. The same is true for the UI e.g. swapping ASP.NET MVC front end for a Java Server Pages implementation.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 22, 2013 at 9:40 am
Gary Varga (8/22/2013)
TBH I cannot remember the last time someone thought of writing SQL statements that were so SQL compliant that they were cross-RDBMS compatible. Most places I have worked develop a RDBMS specific data access layer but some do so whilst ensuring that it takes business entities or data transfer objects (i.e. database neutral types) so that the data access layer/tier can be replaced whilst the remaining parts of the application can remain. The same is true for the UI e.g. swapping ASP.NET MVC front end for a Java Server Pages implementation.
TBHA I cannot remember the last time I did either.
M.
Not all gray hairs are Dinosaurs!
August 22, 2013 at 9:49 am
I think this is where some layer of data access makes sense. Make calls to package/procedures that can be rewritten in a host language. Or use a method in a set of classes that can be replaced when you move from SQL Server to Oracle to MySQL.
Not easy, but not too hard if you build the pattern into your development.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
August 22, 2013 at 11:09 am
Steve Jones - SSC Editor (8/22/2013)
I think this is where some layer of data access makes sense. Make calls to package/procedures that can be rewritten in a host language. Or use a method in a set of classes that can be replaced when you move from SQL Server to Oracle to MySQL.Not easy, but not too hard if you build the pattern into your development.
In writing the internal data layer for a web service a number of years back we took the approach to having one data tier. In the configuration of the service was an option for either Oracle or SQL Server. Then depending on the config setting we were able to execute the correct querybuilder and connection methods for the appropriate database. Worked well. As you say it took some design up front but it worked well.
Not all gray hairs are Dinosaurs!
August 22, 2013 at 1:49 pm
Gary Varga (8/22/2013)
TBH I cannot remember the last time someone thought of writing SQL statements that were so SQL compliant that they were cross-RDBMS compatible. Most places I have worked develop a RDBMS specific data access layer but some do so whilst ensuring that it takes business entities or data transfer objects (i.e. database neutral types) so that the data access layer/tier can be replaced whilst the remaining parts of the application can remain. The same is true for the UI e.g. swapping ASP.NET MVC front end for a Java Server Pages implementation.
I took a PeopleSoft 7 (or maybe 8) training course on developing forms many moons ago.
PS had actually coded forms with both the Oracle and SQL Server SQL statements for all the DML statements. It read the config file and that told it which code to use.
You want to talk about bloatware...
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
August 29, 2013 at 10:58 am
SQLExpress is free of licensing fees. If I am in a position that my server performance needs to exceed that of SQLExpress.... Yeah, the 8K is more than justified. By keeping with SQL Server my code will port immediately to Standard, BI or Enterprise when that need arises.
The only way I'd deviate is if I had the need to exceed SQLExpress and didn't have the money.
-
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply