Replacement for SQL Server Compact (CE)?
-
chrisseanhayes wrote:
people are writing business logic in their SQL.
Hopefully because they realized there is a business need for that. One that is solved by that exact logic. Absolutism such as 'no business logic in the database' can lead to very problematic business solutions. I saw that first hand at a company where the product that was bought as 'database independent' had two guys on site for weeks (and our DBA dedicating a lot of time too) trying to get their app to run anywhere close enough that the company could even conceivably attempt to use it. When I quit that job they were still trying and it was still hours longer than it needed to be. The DBA and I both agreed that the problem was because they were dragging the entire database across the network so they could process it.
every time you use sql server for more than crud then you are married to sql server. joining, aggregating, filtering, projections, unions these are just a few of the business logic decisions totally married to your database implementation. they are next to impossible to implement solely in code without reinventing the wheel. that's just what all these other databases are doing. No-Sql (like Cassandra), kvp (Redis) outside of crud operations they present just as hard of a curve for creating the above needs.
-
every time you use sql server for more than crud then you are married to sql server. joining, aggregating, filtering, projections, unions these are just a few of the business logic decisions totally married to your database implementation. they are next to impossible to implement solely in code without reinventing the wheel. that's just what all these other databases are doing. No-Sql (like Cassandra), kvp (Redis) outside of crud operations they present just as hard of a curve for creating the above needs.
chrisseanhayes wrote:
every time you use sql server for more than crud then you are married to sql serve
False. And I have experience in the following # Applications which used multiple databases. Including stored procedures. # Migrating from one database to another. In one case I did that (me alone) in one week when switching from SQL Server to Oracle. For that case I did have the advantage that I designed and implemented the original layer. What ties one to a database is not the database nor the actual interface to the database but rather inexperienced developers who attempt to solve problems with a lack of knowledge about applications and databases.
chrisseanhayes wrote:
joining, aggregating, filtering, projections, unions
You mean of course...SQL. Yes if one lacks knowledge in that and attempts to roll large enterprises with an ongoing lack of knowledge then that will be a problem. But that is true for everything. If one decides that an entirely new tech stack (with no experience) is the way to go. Or even if one starts a company with only tech guys with no idea how to actually sell or even what the market is.
chrisseanhayes wrote:
they are next to impossible to implement solely in code without reinventing the wheel.
Not even sure what that means. Databases are in fact written code. So yes code can implement joins, etc. But I have also seen inexperienced people attempt to do that in non database code. And I already provided an example of that in the post that you responded to.
chrisseanhayes wrote:
No-Sql (like Cassandra), kvp (Redis) outside of crud operations
I don't believe either example you mentioned is intended to be a full persistence store solution. So not really sure what your point is.
-
chrisseanhayes wrote:
every time you use sql server for more than crud then you are married to sql serve
False. And I have experience in the following # Applications which used multiple databases. Including stored procedures. # Migrating from one database to another. In one case I did that (me alone) in one week when switching from SQL Server to Oracle. For that case I did have the advantage that I designed and implemented the original layer. What ties one to a database is not the database nor the actual interface to the database but rather inexperienced developers who attempt to solve problems with a lack of knowledge about applications and databases.
chrisseanhayes wrote:
joining, aggregating, filtering, projections, unions
You mean of course...SQL. Yes if one lacks knowledge in that and attempts to roll large enterprises with an ongoing lack of knowledge then that will be a problem. But that is true for everything. If one decides that an entirely new tech stack (with no experience) is the way to go. Or even if one starts a company with only tech guys with no idea how to actually sell or even what the market is.
chrisseanhayes wrote:
they are next to impossible to implement solely in code without reinventing the wheel.
Not even sure what that means. Databases are in fact written code. So yes code can implement joins, etc. But I have also seen inexperienced people attempt to do that in non database code. And I already provided an example of that in the post that you responded to.
chrisseanhayes wrote:
No-Sql (like Cassandra), kvp (Redis) outside of crud operations
I don't believe either example you mentioned is intended to be a full persistence store solution. So not really sure what your point is.
thank you, everything you said supported what I said, you just slapped some "no"s in there to make it sound like your answer. kudos superman
-
thank you, everything you said supported what I said, you just slapped some "no"s in there to make it sound like your answer. kudos superman