August 8, 2012 at 4:49 am
Hi,
As per the business requirement, any SQL script that I make should follow ANSI standard, so that it should successfully execute in both SQL Server 2005 and Oracle.
Recently I noticed that for flag columns the datatype VARCHAR(5) is used which will store either 'True' or 'False' inorder to make it executable in Oracle also!. Now I think to use a BIT data type, but it seems Oracle doesn't have such a type. Can I use SMALLINT so that 1 or 0 can be stored? Is this type supported in Oracle?
August 8, 2012 at 8:59 am
Smallint can be used to store 0 or 1, but isn't supported in Oracle (has number datatype).
August 8, 2012 at 11:03 am
SREERAJ. R (8/8/2012)
Hi,As per the business requirement, any SQL script that I make should follow ANSI standard, so that it should successfully execute in both SQL Server 2005 and Oracle.
Recently I noticed that for flag columns the datatype VARCHAR(5) is used which will store either 'True' or 'False' inorder to make it executable in Oracle also!. Now I think to use a BIT data type, but it seems Oracle doesn't have such a type. Can I use SMALLINT so that 1 or 0 can be stored? Is this type supported in Oracle?
I would settle for varchar2(1) and store either "T" or "F" so to make it closer to what you have today.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.August 9, 2012 at 12:45 am
I am afraid Varchar2 will not work in SQL Server...
Is INTEGER supported in Oracle?
Sorry, that I don't have an Oracle installation to test.
August 9, 2012 at 4:23 am
Yes INTEGER is supported. The smallest mutually available data type for this would be CHAR(1) (which is 1 byte in each) and you can use Y/N or T/F or whatever...
August 9, 2012 at 9:29 am
Does your business know how much cost and time they are adding by forcing people to write code that can run on multiple types of DBMS?
This is like saying you need to buy vehicles that can run on either diesel or gasoline and preferably also jet fuel, just so you can use the nearest nozzle at the filling station. It can be done, but the cost and time is horrendous and you get NO business advantage.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
August 9, 2012 at 9:36 am
EdVassie (8/9/2012)
Does your business know how much cost and time they are adding by forcing people to write code that can run on multiple types of DBMS?This is like saying you need to buy vehicles that can run on either diesel or gasoline and preferably also jet fuel, just so you can use the nearest nozzle at the filling station. It can be done, but the cost and time is horrendous and you get NO business advantage.
Hmm, that does depend. I'm not an advocate of needlessly jumping through hoops to make code portable if you're only actually developing against a single platform, but say you work for a software company that wants to ship its product on various database platforms?
Many companies have a strong preference for a particular database platform for their own internal support costs, so it can rule you out of the selection process if your product doesn't support Oracle/SQL Server and a competitor's does.
August 9, 2012 at 9:53 am
True - if you are writing a multi-platform product then you are limited in what you can do, and you have to accept the costs of doing this.
The OP did not sound like this was a multi-platform product, just a IT department dictat (but I could be wrong).
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
August 9, 2012 at 10:10 am
That's where you build a database agnostic DAL and your actual database layer is written to support the RDBMS of choice. To provide a system that performs well on both Oracle and SQL Server, for instance, you should have to separate code bases at the database layer. This allows you to code each to make the best use of the RDBMS features available.
Extra cost, probably. Better performance for the application on both systems, probably. If a customer were to change the RDBMS would you be in a better position to retain the customer, (again) probably.
August 9, 2012 at 10:35 am
Lynn Pettis (8/9/2012)
That's where you build a database agnostic DAL and your actual database layer is written to support the RDBMS of choice. To provide a system that performs well on both Oracle and SQL Server, for instance, you should have to separate code bases at the database layer. This allows you to code each to make the best use of the RDBMS features available.Extra cost, probably. Better performance for the application on both systems, probably. If a customer were to change the RDBMS would you be in a better position to retain the customer, (again) probably.
Agreed on all counts, especially when it comes to the actual application code. In terms of the basic schema design though, it's still a case of working out the closest possible fits in terms of data types and a few small sacrifices for the sake of consistent data across the platforms isn't so awful (although good luck finding consistent data types for dates/times).
August 9, 2012 at 10:41 am
HowardW (8/9/2012)
Lynn Pettis (8/9/2012)
That's where you build a database agnostic DAL and your actual database layer is written to support the RDBMS of choice. To provide a system that performs well on both Oracle and SQL Server, for instance, you should have to separate code bases at the database layer. This allows you to code each to make the best use of the RDBMS features available.Extra cost, probably. Better performance for the application on both systems, probably. If a customer were to change the RDBMS would you be in a better position to retain the customer, (again) probably.
Agreed on all counts, especially when it comes to the actual application code. In terms of the basic schema design though, it's still a case of working out the closest possible fits in terms of data types and a few small sacrifices for the sake of consistent data across the platforms isn't so awful (although good luck finding consistent data types for dates/times).
I will agree to a point. I really do like the SQL Server BIT type for flags that are T/F, Y/N, 0/1 versus using INTs or CHARs. Especially if you have a lot of them. Just think of the space savings if you have 8 of these flags.
August 11, 2012 at 4:35 am
Ed and Howard, That's true. However, the product has been running for a long time and the decision is not with me to separate the logic for different db engines and write different data access layers. So at the moment, I have to live with it.:(
August 11, 2012 at 4:43 am
This is a multi platform product supporting both SQL Server and Oracle.
Finally, I opted for INTEGER instead of VARCHAR(5). The integer will store 0 or 1 instead of 'False' or 'True'.
The comment by Brad given at the end of the following post had a positive influence on this decision:
http://www.sql-server-performance.com/forum/threads/int-vs-char.16020/#post-94491
Reasons given in the post are:
1) INT data types are faster when it come to comparisons especially if you character collation is anything other than binary. With binary collation the disparity is less but still noticable.
2) Certain optimizations done in the server works best for integer data types as compared to character data types.
3) A decrease in size by three bytes for this particular column (if CHAR(1) is used) will not necessarily result in fewer IO's. One will have to analyze the table schema to really quantify this.
Thanks to all replies and inputs.
August 12, 2012 at 4:44 pm
Lynn Pettis (8/9/2012)
That's where you build a database agnostic DAL and your actual database layer is written to support the RDBMS of choice. To provide a system that performs well on both Oracle and SQL Server, for instance, you should have to separate code bases at the database layer. This allows you to code each to make the best use of the RDBMS features available.Extra cost, probably. Better performance for the application on both systems, probably. If a customer were to change the RDBMS would you be in a better position to retain the customer, (again) probably.
+1
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply