Oracle considers empty strings to be NULL while SQL Server does not - how is this best handled?

前端 未结 11 1789
挽巷
挽巷 2021-01-01 13:35

I have to write a component that re-creates SQL Server tables (structure and data) in an Oracle database. This component also has to take new data entered into the Oracle d

相关标签:
11条回答
  • 2021-01-01 14:07

    I don't see an easy solution for this.

    Maybe you can store your values as one or more blanks -> ' ', which aren't NULLS in Oracle, or keep track of this special case through extra fields/tables, and an adapter layer.

    0 讨论(0)
  • 2021-01-01 14:13

    I've written an explanation on how Oracle handles null values on my blog a while ago. Check it here: http://www.psinke.nl/blog/hello-world/ and let me know if you have any more questions. If you have data from a source with empty values and you must convert to an Oracle database where columns are NOT NULL, there are 2 things you can do:

    • remove the not null constraint from the Oracle column
    • Check for each individual column if it's acceptable to place a ' ' or 0 or dummy date in the column in order to be able to save your data.
    0 讨论(0)
  • 2021-01-01 14:15

    I'd go with an additional column on the oracle side. Have your column allow nulls and have a second column that identifies whether the SQL-Server side should get a null-value or empty-string for the row.

    0 讨论(0)
  • 2021-01-01 14:18

    For those that think a Null and an empty string should be considered the same. A null has a different meaning from an empty string. It captures the difference between 'undefined' and 'known to be blank'. As an example a record may have been automatically created, but never validated by user input, and thus receive a 'null' in the expectation that when a user validates it, it will be set to be empty. Practically we may not want to trigger logic on a null but may want to on an empty string. This is analogous to the case for a 3 state checkbox of Yes/No/Undefined.

    Both SQL and Oracle have not got it entirely correct. A blank should not satisfy a 'not null' constraint, and there is a need for an empty string to be treated differently than a null is treated.

    0 讨论(0)
  • 2021-01-01 14:19

    My typical solution would be to add a constraint in SQL Server forcing all string values in the affected columns to have a length greater than 0:

    CREATE TABLE Example (StringColumn VARCHAR(10) NOT NULL)
    
    ALTER TABLE Example
    ADD CONSTRAINT CK_Example_StringColumn CHECK (LEN(StringColumn) > 0)
    

    However, as you have stated, you have no control over the SQL Database. As such you really have four choices (as I see it):

    1. Treat empty string values as invalid, skip those records, alert an operator and log the records in some manner that makes it easy to manually correct / re-enter.
    2. Convert empty string values to spaces.
    3. Convert empty string values to a code (i.e. "LEGACY" or "EMPTY").
    4. Rollback transfers that encounter empty string values in these columns, then put pressure on the SQL Server database owner to correct their data.

    Number four would be my preference, but isn't always possible. The action you take will really depend on what the oracle users need. Ultimately, if nothing can be done about the SQL database, I would explain the issue to the oracle business system owners, explain the options and consequences and make them make the decision :)

    NOTE: I believe in this case SQL Server actually exhibits the "correct" behaviour.

    0 讨论(0)
提交回复
热议问题