I am working on a business app (asp.net). Right now I am using sql server. But I plan to support at least mysql and postgresql down the road.
What are the issues that I should consider to avoid future headaches? Especially about datatypes (column types). E.g. I think BIT column is not supported on some dbs so I use tinyint?
I mostly use plain sql (no entity framework or linq, etc) and try to keep it as simple as I can.
I am NOT using things like triggers, etc.
I do use stored procedures but they can be replaced with plain sql if I have to.
Your only hope is to separate data access into a proper data access layer, as Remus Rusanu suggests. The data access layer can have one consistent interface to the rest of your code, and be changed out for other versions for each DB platform. Keeping the SQL fairly standard will help, but it's not really possible to write one body of SQL code and have it work everywhere (the SQL standard isn't that well implemented.)
Consider (with some costs in term of learning curve) the adoption of a Domain Model and a data access layer based on an OR/M like NHibernate (https://www.hibernate.org/343.html)
Make sure you write all your client code using the abstract IDbConnection, IDbCommand, IDataReader instead of the concrete. You will also have to keep your SQL statements in check all the time to ensure you use only compatible syntax.
You can also try connecting via the OdbcConnection/OdbcCommand components and use generic ODBC syntax and generic ODBC data types (ie. the {fn SUBSTRING(...)} stuff, aka. the ODBC Escaped Syntax).
As an alternative what I prefer to do is to isolate the data access and create specific DAL classes for each back end. I use XML and XSLT to generate the DAL code. Similar to this the technique of integrating XSLT code generation from my blog, but with XSLTs geared specifically for each back-end specific code.
Related
Is there currently anything in the 2sxc module that allows you to connect to other database types? Specifically I would like to connect to a MySQL database. I know you can connect to other tables within the database.
This depends a bit on your question. Let's split
Can you use Razor-Views in 2sxc to visualize data from any kind of database?
Yes, just use c# code to get the data. Just create the sql-objects or whatever in .net and use that. For example, I wrote about using PetaPoco http://2sxc.org/en/docs/docs/feature/feature/2583
Can you use non-sql-data in your Visual Query Designer
Yes, but you'll have to work a bit. The easiest way is to map your my-sql tables in the DNN SQL server. This is a bit like a translation layer, which then let's use use them as if they were in the SQL Server.
A harder way is to create your own data source. Best to inherit the SqlDataSource (which provides a lot of security around parameter injection etc.) https://github.com/2sic/eav-server/blob/master/ToSic.Eav.DataSources/SqlDataSource.cs - and then modify it to use your mysql
As a Front end developer I have less knowledge on Databases. But recently we started to develop an CRM application.
My question is, how feasible to migrate from one database to other. Lets say our application now supports mysql but later customer comes up with IBM's DB2 or sql lite. What are the things that we need to take care while developing to support easy migration ?
How cloud will help to solve my problem?
Just keep your data model separate from actual database calls and you should be good. Use a database abstraction layer in your model to make calls to the database. You'll only have to change the bottom layer for specific databases.
Some best practices:
Avoid DBMS specific features, data types and SQL/DDL constructs; keep to the SQL[92] standard. Test against e. g. SQLite, which keeps rather close to the standard.
Use an Entity Relationship Modeling tool that supports exporting DDL files for all targeted DBMS, or to standard SQL. Or write and maintain your DDL scripts by hand. Vendor specific tools usually don't do this.
Use the existing SQL abstraction layer that comes with your language/toolkit/environment, or implement one with an eye on portability (which reinvents the wheel another time).
Keep the logic in your application; the DB is for data only. Avoid triggers, stored procedures etc.
Generally apply the KISS principle to your data storage.
You may get more help on specific questions about general/abstract issues (not the implementation details, which belong here) over at Programmers.
I have a core data schema file with relationships between the entities.
I need to create a SQL database and would like to know if it can be created automatically (MySql or MS-SQL) using only this file.
Looking at the SQLite DB I see that the relationships are not mapped in any logical way.
First, your assessment that the relationships are "not mapped in any logical way" is not correct. If you look carefully at the Core Data generated database you will discover that the relationships are mapped exactly as in any other old relational database scheme, i.e. with foreign keys referring to rows in other tables.
Also, the naming conventions in these SQLite databases are very transparent (e.g., entity and attribute names start with Z, etc.
That being said, I would strongly discourage you to hack the Core Data generated database file, or even to use it to inform another database scheme, the reason being that these are undocumented features that could change any time without notice and thus break any code you write based on them.
IMO, the most practical thing to do is to rewrite the model quickly in the usual MySQL schema format and update it manually as well when you change the managed object model.
If you would like to automate the process, there is a rich set of APIs provided for interpreting and parsing NSManagedObjectModel, including classes like NSEntityDescription, NSAttributeDescription etc. You could write a framework that iterates though your entities and attributes and generates a text file that is a readable schema for MySQL, complete with information about indexing, versions etc..
If you go down that route, please make sure to notify us and do post your framework on Github for the benefit of others.
If you use Core Data you can create an SQL based database using a schema file but its structure is entirely controlled by the Core Data framework. Apple specifically tell us as developers to leave it alone and do not edit it using libsqlite or any other method. If you do then Core Data won't have anything to do with you!
In terms of making your own DB using one of Apple's schema files, I'm sure it is possible, but you'd have to know the inner workings of the Core Data framework to even attempt it.
In terms of making your own SQLite DB then you have to sort out all the relationships and mapping yourself.
I think that mixing and matching Core Data resources and custom built SQLite databases is probably a headache waiting to happen. I have used both methods and find that Core Data is brilliant (especially with iCloud) as long as you're OK with your App being limited to Apple only.
We're working on an ASP.NET web application with C# code behind. The database is MySQL 5.1 using InnoDB. The data access layer uses ADO.NET to call stored procedures and then builds various data structures out of the result sets (no object mapping). This works fine, but it is a little verbose.
Not surprisingly, we made some mistakes when designing the first version of our data model, but the experience has made us smarter and we decided to refactor the data model. We don't have to change our data access layer, but we are considering our options for that as well.
It's been difficult for us to ignore the popularity of ORM tools these days; we feel like we are way behind or something for not being familiar with them. Not only that, but we have already designed an object model that nicely describes our data model. The main ORM tools we would consider are NHibernate, ADO.NET Entity Framework, and LINQ to SQL. We would prefer LINQ to SQL because we have read (on S.O.) that it is more light weight than full ORM tools.
We think one drawback to using an ORM tool is the learning curve, but we can already see how using LINQ could reduce the amount of code we will have to write, which could save us time in the long run. However, we are using MySQL, not SQL Server.
So my question is, would DBLinq work well enough for a production system? Or, is LINQ to SQL a compeling enough reason for us to make the move to SQL Server 2008? Incedentally, I'd prefer to use SQL Server over MySQL, but cost is the obvious drawback. After 3 years on BizSpark, we'd be on the hook for $6K. Or, should we consider other ORM tools instead? Or, should we just ignore the hype and not use an ORM tool, but maybe take advantage of LINQ to DataSet?
I searched S.O. for info on DBLinq, but only found 17 questions with the DBLinq tag, so it doesn't appear to be popular.
EDIT
Looks at though dotConnect for MySQL has support for LINQ, so that's another option.
Can anyone speak to how well that driver works for writing LINQ queries?
Check bl-toolkit. It's free, very fast and has great LINQ support. Newest addition are T4 templates for generating your data model from database.
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.