I don't think that this is a very good idea, because unicode is twice the size (2 byte) as ASCII. For the system tables this might not be a problem, but as soon as you store a large amount of data you might run into size problems. I find performance and efficiency more important in real life applications than the ease of the configuration task.I agree.
Arne
Especially with the fact that keys are limited to 254 characters or 126 unicode characters.
126 is way too short for many key columns out there (think of filenames etc.)
I believe that a modern database should handle strings differently than SapDB or Oracle today.
All Strings should reside in a single sorted "constant pool" of the database (with reference count) and actual string occurences should only be references to this pool. This would particularly improve performance of joins using character columns (because such joins would only use the references, not the strings themselves).
Because disk space has grown so rapidly, past assumptions that applications do not use long strings as foreign keys do not hold true anymore.
Introduction of Unicode characters therefore mandates a redesign of the internal string handling within the database along the lines described above.
Of course, this is my personal opinion only.
Regards,
Falk
P.S.
Before all, sql queries should deliver correct results which SapDB does not (see my other posting). Robustness and performance before features.
--
Dr. Falk Langhammer
Living Pages Research GmbH
Kolosseumstr. 1a D-80469 Munich, Germany
mailto:[EMAIL PROTECTED] http://www.living-pages.de
Phone +49 (89) 189 207-27 Fax +49 (89) 189 207-29
Mobil +49 (171) 79 39 667
mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
