Application & Database architechture

Whenever I design a database (currently SQL Server), I always wonder what if in future I had to migrate to another database (Oracle, MySql) is a best way of take some important parameters into consideration like naming conventions (tables, columns including the length), data types, etc. Quite often I ask myself the following questions:

Should i name my tables, columns plural/descriptive? Should I prefix tables/columns, use underscores or any other identifier in the names? Should the names be of a special/specific casing?

I am trying to address the design from the development point o view , ie .NET (by primary skill set), hence should there be any stored preocedures at all? If not what is the alternative for an easy migration? Are there any recommended guidelines which someone can suggest bearing in mind both database & .NET design architechture in mind?


Converting from one DB type to another is really quite rare: in 35 years I've done it once: from Oracle to SQL Server. That was an exceptional circumstance: a very old version of Oracle running on a VAX that had not been supported by anyone for years and which had to be got rid of. The Management decreed (rightly, I think) that as the standard DBMS we were by then using was QL Server the system should be converted.

MS has a conversion tool for this and we used it. I worked pretty well, but since PL/SQL is so different from T/SQL the complex stored procedures, while they worked, were unmaintainable and very slow so we redid them in T/SQL from scratch - which took quite a lot of time. That was the only problem, though.

My personal approach is to minimise the use of SP's anyway. If you are processing cursors row-by-row in an SP then in my opinion you are doing it wrong. Anything which processes RAT (Row-At-a-Time) should be in code; anything that can process Sets of data should be in an SP.

Unless you have a reason to think you will need to convert I wouldn't worry about it. If you do, as long as you do sensible things with naming conventions there shouldn't be a problem. Things you will have problems with are:

  • T/SQL code does not translate easily to PL/SQL (Don't know the MySQL language but I'd assume problems)
  • Hierarchical queries (CTE's) won't translate and will have to be re-written for Oracle. They aren't supported on MySQL AFAIK.
  • Converting from IDENTITY columns to Oracle Sequences shouldn't be a big problem (or does Oracle now support something closer?) Don't know about other DBMS's.
  • But as I say, it's not something I'd normally worry about.


    Did you try to use ORM, for example Entity Framework with code-first approach? It helps to avoid database specific stuff in your code, also it provides very flexible migration mechanism.

    链接地址: http://www.djcxy.com/p/41316.html

    上一篇: git标签有一个标准的命名约定吗?

    下一篇: 应用程序和数据库架构