#26683: Oracle DBs: Add option to use VARCHAR2 data type
--------------------------------+--------------------------------------
Reporter: elarandjelovic | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: 1.9
Severity: Normal | Resolution: wontfix
Keywords: Oracle | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+--------------------------------------
Comment (by VackarAfzal):
The industry standard seems to to be VARCHAR2, with support for NVARCHAR2
really there for legacy purposes.
I've encountered issues where existing oracle code was all VARCHAR2, as
per our (and probably most) DBA's spec, but django fields were NVARCHAR2,
when joining data accross these schemas it would take 20 minutes to
complete, changing the field to VARCHAR2 resulted in the same query
executing in 200ms.
My suggestion would be to default to using VARCHAR2 for everything UNLESS
the database has not been setup with unicode support. Checking for this is
pretty straightforward:
{{{
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' ;
}}}
If you get this is a result, you're OK
{{{
AL32UTF8
}}}
If not then fallback to NVARCHAR2 if unicode support is required.
--
Ticket URL: <https://code.djangoproject.com/ticket/26683#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/072.81f6a4e28da11d4bed5ac986de65ff63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
