All of these databases have to set to accept UTF-8 compliant character sets to prevent corruption of non-ASCII characters.
Loaded via the bulk loader.
DB2 has two severe limitations
- Tables may contain only 500 columns
- The potential width of all data must not exceed the database block size, which can be no greater than 32k, whether or not even the potential block size can be exceeded. Other DBMS platforms can create tables with the potential to create very verbose data but will fail at record insertion time only if the actual data exceeds the block size. DB2 won’t even let you create the columns that would allow you do to this. Since Salesforce objects typically have so many large text fields, nearly all text fields have to be defined as CLOB data types instead of VARCHAR, which means the record is physically stored in many separate database blocks, increasing the I/O and decreasing performance.
Loaded by the bulk loader.
MySQL has two limitations that can usually be dealt with
- A single row cannot contain more data than the block size, but you make CLOBs out of the large VARCHAR fields using the.
- You’ll have to adjust /etc/my.cnf parameters as follows to accommodate your particular needs, using your best judgment as to what the exact values should be:
[mysqld] default-storage-engine=INNODB max_allowed_packet=32000000 innodb_buffer_pool_size=134217728 open_files_limit=10000 max_connections=500
Excellent DBMS for flexibility. Spans database block size if data exceeds the width of the block. Requires a high level of skill to administer.
Excellent DBMS for flexibility. Spans database block size if data exceeds the width of the block. Very easy to administer.
- A single row cannot contain more data than the block size, unless you make CLOBs out of the large VARCHAR fields.
- 16k limit on long text fields, which is a challenge because Salesforce allows 32k fields