4 ms·
Uh, shouldn't you use the most appropriate type available to describe your data, since that will simplify the process if you ever need to migrate to a different
by nness 13y ago
Uh, shouldn't you use the most appropriate type available to describe your data, since that will simplify the process if you ever need to migrate to a different DBMS?
- deleted 13y ago[deleted]
- bunderbunder 13y agoNowadays the most appropriate type available to describe your data is a non-standard type that's specific to the RDBMS you're using, often as not. With SQL databases, you can generally only pick one of the following: 1. Any kind of expectation of hassle-free migration to a different RDBMS. 2. Benefiting from much of anything that's happened in any dialect of SQL since about the time Windows 3.1 hit the market. Personally, I generally prefer #2, because #1 is kind of a myth anyway. For example, PosgtgreSQL's VARCHAR type has different semantics from Oracle's: One supports Unicode and the other doesn't.
- Pxtl 13y agoMicrosoft follows Oracle's approach and uses NVARCHAR to describe their infernal 2-byte format that might be UCS2-wrongendian or it might be UTF-16 depending on their mood and the tool you're using at the moment. Naked VARCHAR means you have to pick an 8-bit character-set like a savage.
- bunderbunder 13y agoYa, or for Oracle you might be better off using VARCHAR2, which uses UTF-8. That way you aren't mired in savagery, but don't have to pay the performance hit of storing 2 bytes per character for text that's mostly in western European languages. Whereas SQL Server users are stuck choosing between doubling up on I/O and suffering codepages. Meanwhile in PostgreSQL you just use regular VARCHAR and pick utf8 as your character set like a proper subgenius. Fun fact: In earlier versions of Portal, it was database portability that GlaDOS promised to give you after the experiment.