We are looking to use WSO2 API manager at our current client, and are required to use the provided Oracle DDL to set up the necessary tables for Carbon, API manager and message broker. The Client's dba's are coming back asking why the script uses varchar instead of Varchar2 for the relevant fields, which is a good question as the standard approach for oracle is "Varchar2 is the industry standard, don't use varchar."
Is there a really good reason why the oracle scripts use Varchar instead of Varchar2? When implemented on top of Oracle, what is WSO2 doing that required the ability to differentiate null from empty?
This was probably a simple typo that doesn't matter.
It looks like only the column AM_API.INDEXER uses VARCHAR instead of VARCHAR2. The program also contains scripts for H2, MS SQL, MySQL, and PostGreSQL. All the other databases use VARCHAR. This is a pretty common mistake for products that support multiple databases.
Keep in mind that there is no meaningful difference between VARCHAR and VARCHAR2 in Oracle. The documentation claims that someday there will be a difference but I highly doubt it. This issue has existed for a long time and there's a ton of legacy code that depends on the old behavior. I would bet good money that Oracle will never make VARCHAR use different NULL comparison semantics.
I tried to change the script and created a pull request. I don't understand this project and almost certainly did something wrong. So don't be surprised if the request is rejected. But perhaps it will in some way help to lead toward a fix.
Related
We are planning a new system for a client in ORACLE 11g. I've been mostly in the Sql Server world for several years, and am not really current on the latest ORACLE updates.
One particular feature I'm wondering if ORACLE has added in by this point is some sort of logical "container" for database objects, akin to Sql Server's SCHEMA.
Trying to use ORACLE's schemas like Sql Server winds up being a disaster for code comparisons when trying to push from dev > test > live.
Packages are sort of similar, except that you can't put tables into a package (so they really only work for logical code grouping).
The only other option I am aware of is the archaic practice of having to prefix object names with a "schema" prefix, i.e. RPT_REPORTS, RPT_PARAMETERS, RPT_LOGS, RPT_USERS, RPT_RUN_REPORT(), with the prefix RPT_ denoting that these are all the objects dealing with our reporting engine say. Writing a system like this feels like we never left the 8.3 file-naming age.
Is there by this point in time any cleaner, more direct way of logically grouping related objects together in ORACLE?
Oracle's logical container for database objects IS the schema. I don't know how much "cleaner" and "more direct" you can get! You are going to have to do a paradigm shift here. Don't try to think in SQL Server terms, and force a solution that looks like SQL Server on Oracle. Get familiar with what Oracle does and approach your problems from that perspective. There should be no problem pushing from dev to test to production in Oracle if you know what you're doing.
It seems you have a bit of a chip on your shoulder about Oracle when you use terms like "archaic practice". I would suggest you make friends with Oracle's very rich and powerful feature set by doing some reading, since you're apparently already committed to Oracle for this project. In particular, pick up a copy of "Effective Oracle By Design" by Tom Kyte. Once you've read that, have a look at "Expert Oracle Database Architecture" by the same author for a more in-depth look at how Oracle works. You owe it to your customer to know how to use the tool you've been handed. Who knows? You might even start to like it. Think of it as another tool in your toolchest. You're not married to SQL Server and you're not being unfaithful by using Oracle ;-)
EDIT:
In response to questions by OP:
I'm not sure why that is a logistical problem. They can be thought of as separate databases, but physically they are not. And no, you do not need a separate data file for each schema. A single datafile is often used for all schemas.
If you want a "nice, self-contained database" ala SQL Server, just create one schema to store all your objects. End of problem. You can create other users/schemas, just don't give them the ability to create objects.
There are tools to compare objects and data, as in the PL/SQL Developer compare. Typically in Oracle you want to compare schemas, not entire databases. I'm not sure why it is you want to have multiple schemas each with their own objects anyway. What does is buy you to do that? Keep your objects (tables, triggers, code, views, etc.) in one schema.
I'm writing an assignment for a databases class, and we're required to migrate our existing relational schema to Oracle objects. This whole debacle has got me wondering, just how widely used are these things? The data model is wonky, the syntax is horrendous, and the object orientation is only about three quarters of the way implemented.
Does anyone actually use this?
For starters some standard Oracle functionality uses Types, for instance XMLDB and Spatial (which includes declaring columns of Nested Table data types).
Also, many PL/SQL developers use types all the time, for declaring PL/SQL collections or pipelined functions.
But I agree few places use Types extensively and build PL/SQL APIs out of them. There are several reasons for this.
Oracle has implemented Objects very slowly. Although they were introduced in version 8.0 it wasn't until 9.2 that they fully supported Inheritance, Polymorphism and user-defined constructors. Proper Object-Oriented Programming is impossible without those features. We didn't get SUPER() until version 11g. Even now there are features missing, most notably the private declarations in the TYPE BODY.
The syntax is often clunky or frustratingly obscure. The documentation doesn't help.
Most people working with Oracle tend to come from the relational/procedural school of programming. This means they tend not to understand OOP, or they fail to understand where it can be useful in database programming. Even when people do come up with a neat idea they find it hard or impossible to implement using Oracle's syntax.
That last point is the key one. We can learn new syntax, we can persuade Oracle to complete the feature set, but it is only worthwhile if we can come up with a use for Types. That means we need problems which can be solved using Inheritance and Polymorphism.
I have worked on one system which used types extensively. It was a data warehouse system, and the data loading sub-system was built out of Types. The underlying rationale was simple:
we need to apply the same business rule template for every table we load, so the process is generic;
every table has its own projection, so the SQL statements are unique for each one.
The Type implementation is clean: the generic process is defined in a Type; the implementation for each table is defined in a Type which inherits from that generic Type. The specific types can be generated from metadata. I presented on this topic at the UKOUG a few years ago, and I have written it up in more detail on my blog.Find out more.
By the way, Relational Theory includes the concept of Domains, which are user-defined data-types, including constraints, etc. No flavour of RDBMS actually supports Domains but Oracle's Type Implementation is definitely a step along the way.
I've never seen the benefit to it, mostly because when I last examined it, your object definitions were immutable once they were used by a table.
So if you had an Address object you used in a Customer table definition, you could never ever change the Address object definition without dropping the Customer table, or having to go through a very wonky conversion.
Objects are fine for data instantiation - like what an application does - but for data storage and set-based manipulation, well, I simply don't see the point.
Many of the other answers have given good examples of where using objects does make sense; in general these are to handle some particular, perhaps complex, types of data. Oracle itself uses them for geospatial data.
What is not commonly done, except it would sadly appear in some college courses, is to use object-based tables instead of regular relational tables to hold regular data like employees and departments something like this:
create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;
While these may be nice simple examples to teach the concepts, I fear they may lead to a new generation of database developers who think this approach is suitable, more modern and therefore better than "old-fashioned" relational tables. It emphatically is not.
I've only heard of it being used one place, and the developers involved were converting to get away from it. I've thought of using it purely in PL/SQL, but as our DBA's won't let us install any Types for fear that we might use them in a table this is unlikely to happen.
Share and enjoy.
It's not too uncommon to see them play a small role somewhere in your system. For example, if you're doing something with Oracle data cartridge. Some times when you need to do something really weird they are necessary.
It is uncommon to see them used extensively in a system. I've seen two different systems use a lot of objects and it was a disaster both times: difficult to use, very slow, and full of bugs.
"Simple" relational methods that use basic tables, rows, and columns are almost always good enough. Every programmer (and program) can understand these concepts, and they are powerful enough for almost any task. Yet you can spend many years trying to fully understand and optimize these methods. Object relational technology adds a huge amount of complexity on top of that for very little gain.
I've used simple types with constructors and a few methods to wrap some functionality of interacting with an existing tcp server. I needed to pass x bytes (raw object) and receive back x bytes (clean object). I could have written some procedure that was particular to my task, but using object type allowed this to be a bit more generic for others. Nothing fancy, very basic OO stuff, create the raw object, populate a handful of its 100 or so properties, call its clean function, and assign the result to a new "clean" object. Anyone else who wanted to call the tcp server could follow the same basic steps, only populating whatever raw values with their data.
Still, in my experience I wouldn't say Oracle is object oriented, but rather has some basic functionality of objects. And as others said, companies don't buy Oracle for it OO capabilities. Don't get too caught up in it with Oracle imo.
I would have to say it's not why people buy Oracle. It's very non-portable/non-standard, and as Adam pointed out has some usage pitfalls as well. I've not personally seen the benefit to it. I don't know how widespread it's usage is, but I can't imagine it's very big. Take a look around this site to see how many questions are asked about it. That may give you some insight.
Well never used them in my practice, never heard anyone using them either, not widely used i guess, It matters when you have an object oriented database, oracle supports OO but is not an OO database. I think people who migrate from OO databases to Oracle use them widely
We are going to migrate an application to have it support Unicode and have to choose between unicode character set for the whole database, or unicode columns stored in N[VAR]CHAR2.
We know that we will no more have the possibility of indexing column contents with Oracle Text if we choose NVARCHAR2, because Oracle Text can only index columns based on the CHAR type.
Apart that, is it likely that other major differences arise when harvesting from Oracle possibilities?
Also, is it likely that some new features are added in newer versions of Oracle, but only supporting either CHAR columns or NCHAR columns but not both?
Thank you for your answers.
Note following Justin's answer:
Thank you for your answer. I will discuss your points, applied to our case:
Our application is usually alone on the Oracle database and takes care of the
data itself. Other software that connect to the database are limited to Toad,
Tora or SQL developer.
We also use SQL*Loader and SQL*Plus to communicate with the database for basic
statements or to upgrade between versions of the product. We have
not heard of any specific problem with all those software regarding NVARCHAR2.
We are also not aware that database administrators among our customers would
like to use other tools on the database that could not support data on
NVARCHAR2 and we are not really concerned whether their tools might disrupt,
after all they are skilled in their job and may find other tools if necessary.
Your last two points are more insightful for our case. We do not use many
built-in packages from Oracle but it still happens. We will explore that
problem.
Could we also expect performance breakage if our application (that is compiled under Visual C++), that uses wchar_t to
store UTF-16, has to perform encoding conversions on all processed data?
If you have anything close to a choice, use a Unicode character set for the entire database. Life in general is just blindingly easier that way.
There are plenty of third party utilities and libraries that simply don't support NCHAR/ NVARCHAR2 columns or that don't make working with NCHAR/ NVARCHAR2 columns pleasant. It's extremely annoying, for example, when your shiny new reporting tool can't report on your NVARCHAR2 data.
For custom applications, working with NCHAR/ NVARCHAR2 columns requires jumping through some hoops that working with CHAR/ VARCHAR2 Unicode encoded columns does not. In JDBC code, for example, you'd constantly be calling the Statement.setFormOfUse method. Other languages and frameworks will have other gotchas; some will be relatively well documented and minor others will be relatively obscure.
Many built-in packages will only accept (or return) a VARCHAR2 rather than a NVARCHAR2. You'll still be able to call them because of implicit conversion but you may end up with character set conversion issues.
In general, being able to avoid character set conversion issues within the database and relegating those issues to the edge where the database is actually sending or receiving data from a client makes the job of developing an application much easier. It's enough work to debug character set conversion issues that result from network transmission-- figuring out that some data got corrupted when a stored procedure concatenated data from a VARCHAR2 and a NVARCHAR2 and stored the result in a VARCHAR2 before it was sent over the network can be excruciating.
Oracle designed the NCHAR/ NVARCHAR2 data types for cases where you are trying to support legacy applications that don't support Unicode in the same database as new applications that are using Unicode and for cases where it is beneficial to store some Unicode data with a different encoding (i.e. you have a large amount of Japanese data that you would prefer to store using the UTF-16 encoding in a NVARCHAR2 rather than the UTF-8 encoding). If you are not in one of those two situations, and it doesn't sound like you are, I would avoid NCHAR/ NVARCHAR2 at all costs.
Responding to your followups
Our application is usually alone on
the Oracle database and takes care of
the data itself. Other software that
connect to the database are limited to
Toad, Tora or SQL developer.
What do you mean "takes care of the data itself"? I'm hoping you're not saying that you've configured your application to bypass Oracle's character set conversion routines and that you do all the character set conversion yourself.
I'm also assuming that you are using some sort of API/ library to access the database even if that is OCI. Have you looked into what changes you'll need to make to your application to support NCHAR/ NVARCHAR2 and whether the API you're using supports NCHAR/ NVARCHAR2? The fact that you're getting Unicode data in C++ doesn't actually indicate that you won't need to make (potentially significant) changes to support NCHAR/ NVARCHAR2 columns.
We also use SQL*Loader and SQL*Plus to
communicate with the database for
basic statements or to upgrade between
versions of the product. We have not
heard of any specific problem with all
those software regarding NVARCHAR2.
Those applications all work with NCHAR/ NVARCHAR2. NCHAR/ NVARCHAR2 introduce some additional complexities into scripts particularly if you are trying to encode string constants that are not representable in the database character set. You can certainly work around the issues, though.
We are also not aware that database
administrators among our customers
would like to use other tools on the
database that could not support data
on NVARCHAR2 and we are not really
concerned whether their tools might
disrupt, after all they are skilled in
their job and may find other tools if
necessary.
While I'm sure that your customers can find alternate ways of working with your data, if your application doesn't play nicely with their enterprise reporting tool or their enterprise ETL tool or whatever desktop tools they happen to be experienced with, it's very likely that the customer will blame your application rather than their tools. It probably won't be a show stopper, but there is also no benefit to causing customers grief unnecessarily. That may not drive them to use a competitor's product, but it won't make them eager to embrace your product.
Could we also expect performance
breakage if our application (that is
compiled under Visual C++), that uses
wchar_t to store UTF-16, has to
perform encoding conversions on all
processed data?
I'm not sure what "conversions" you're talking about. This may get back to my initial question about whether you're stating that you are bypassing Oracle's NLS layer to do character set conversion on your own.
My bottom line, though, is that I don't see any advantages to using NCHAR/ NVARCHAR2 given what you're describing. There are plenty of potential downsides to using them. Even if you can eliminate 99% of the downsides as irrelevant to your particular needs, however, you're still facing a situation where at best it's a wash between the two approaches. Given that, I'd much rather go with the approach that maximizes flexibility going forward, and that's converting the entire database to Unicode (AL32UTF8 presumably) and just using that.
Most forums cite minor differences in speed, backup, etc.
It's about time someone tell how the two differ when it comes to GUI data validation.
Do this 2 Database always depend on java(or other software), or do they have the ability to create a user interface the accepts only valid input. Things like: positive numbers only, age between 1 to 100 only, email must be correct. I would be scared if my software accepts 500 years old for age.
Both offer native development tools that are roughly comparable and able to what you ask about.
Both also offer the ability for all main languages to interact with the RDBMS and so therefore the ability to to do the type of thing you discuss is as diverse as the options of a range of languages including Java, .Net, Ruby, Python, C++, VB, etc, etc
However what they don't really offer is a simple Access type 'forms and tables' type RAD tool. In simple terms the increased flexibility and power of both Oracle and DB2 comes at the price of simplicity.
Neither database DEPENDS on Java for implementing field level constraints. Data constraints can be implemented directly at the database level, and it is good practice to do so.
But you also need field level validation - users do not want to get constraint violation errors on insert.
As for tools that generate GUI applications from the database itself - I don't see that as an Oracle vs DB2 database question - it's more Oracle Apex vs IBMs equivalent - but even within Oracle you've got Forms (deceased), JDeveloper, Apex.
I am developing a enterprise software for a big company using Oracle. Major processing unit is planned to be developed in PL/SQL. I am wondered if there is any ORM like Hibernate for Java, but the one for PL/SQL. I have some ideas how to make such a framework using PL/SQL and Oracle system tables, but it is interesting - why no one have done this before? What do you think will that be effective in speed and memory consumption? Why?
ORMs exist to provide an interface between a database-agnostic language like Java and a DBMS like Oracle. PL/SQL in contrast knows the Oracle DBMS intimately and is designed to work with it (and a lot more efficiently than Java + ORM can). So an ORM between PL/SQL and the Oracle DBMS would be both superfluous and unhelpful!
Take a read through these two articles - they contain some interesting points
Ask Tom - Relational VS Object Oriented Database Design
Ask Tom - Object relational impedance mismatch
As Tony pointed out ORMs really serve as helper between the App and Db context boundaries.
If you are looking for an additional level of abstraction at the database layer you might want to look into table encapsulation. This was a big trend back in the early 2000s. If you search you will find a ton of whitepapers on this subject.
Plsqlintgen still seems to be around at http://sourceforge.net/projects/plsqlintgen/
This answer has some relevant thoughts on the pros and cons of wrapping your tables in pl/sql TAPIs (Table APIs) for CRUD operations.
Understanding the differences between Table and Transaction API's
There was also a good panel discussion on this at last years UK Oracle User Group - the overall conclusion was against using table APIs and for transaction APIs, for much the same reason - the strength of pl/sql is the procedural control of SQL statements, while TAPIs push you away from writing set-based SQL operations and towards row-by-row processing.
The argument for TAPI is where you may want to enforce some kind of access policy, but Oracle offers a lot of other ways to do this (fine-grained access control, constraints, triggers on insert/update/etc can be used to populate defaults and enforce that the calling code is passing a valid request).
I would definitely advise against wrapping tables in PL/SQL object types.
A lot of the productivity with pl/sql comes from the fact that you can easily define things in terms of the underlying database structure - a row record type can be simply defined as %ROWTYPE, and will be automatically impacted when the table structure changes.
myRec myTable%ROWTYPE
INSERT INTO table VALUES myRec;
This also applies to collections based over these types, and there are powerful bulk operations that can be used to fetch & insert whole collections.
On the other hand, object types must be explicitly impacted each time you want to change them - every table change would require the object type to be impacted and released, doubling your work.
It can also be difficult to release changes if you are using inheritance and collections of types (you can 'replace' a package, but cannot replace a type once it is used by another type).
This isn't putting OO PL/SQL down - there are places where it definitely simplifies code (i.e. avoiding code duplication, anywhere you would clearly benefit from polymorphism) - but it is best to understand and play to the strengths of the language, and the main strength is that the language is tightly-coupled to the underlying DB.
That said, I do often find myself creating procedures to construct a default record, insert a record, etc - often enough to have editor macros for it - but I've never found a good argument for automatically generating this code for all tables (a good way to create a lot of unused code??)
Oracle is a Relation database and also has the ability to work as an object-oriented database as well. It does this by building an abstraction layer (fairly automatically) on top of the relational structure. This would seemingly eliminate the need for any "tool" as it is already built-in.