Lessons from EnterpriseDB
I had a nice conversation yesterday with Jim Mlodgenski of EnterpriseDB, covering both generalities and EnterpriseDB-specific stuff. Many of the generalities were predictable, and none were terribly shocking. Even so, I am dressed as Captain Obvious, and shall repeat a few of the ones I found interesting below:
1. Part of the drive to database centralization is driven by non-technical factors such as compliance regulations and database licensing fees. Even where database modularity – i.e., DBMS2 — makes a lot of sense, it may be artificially restricted. Ironically, this is also leading to increased use of database federation, in which a portion of a database may run at a central site but reach out to tables on distributed servers.
2. Most referential integrity is declarative these days. Triggers, while still used a little for referential integrity, are mainly used for auditing and compliance. Stored procedures are, beyond that, used for performance, e.g. whittling down result sets before shipping them to the middle tier. They also are used for security, by controlling the routes of table access (this use is commonly a performance hog).
3. EnterpriseDB supports multiple stored procedure languages. The most important is its PL-SQL clone. Otherwise, Perl is actually used sometimes for performance reasons, namely in heavy-duty text processing (e.g., building XML documents). And Java is sometimes used to offload middle-tier-style functionality, especially for connectivity. (Replace mid-tier polling with stored procedures and you save a lot of query traffic …)
4. EnterpriseDB supports a form of native XML (you can retrieve portions of documents) but not shredding. This is used mainly in data interchange scenarios. Spatial datatypes are used for a variety of purposes, mainly maps and predictive analytics on maps (e.g., traffic jam and land mine locations, thankfully not in the same application). Also MRI scans. But RFID isn’t a factor yet. Also useful is an IP address datatype – e.g., you can query directly on subnets in security applications.
That’s all for now. I plan to post about more nitty-gritty stuff another time.
Comments
2 Responses to “Lessons from EnterpriseDB”
Leave a Reply
Why wasn’t this posted with “PostgreSQL” tag? EnterpriseDB is just a branding and slight modification to PostgreSQL
Well, “slight” is open to discussion.
That said, I absolutely meant to post it with a PostgeSQL tag, and am fixing it now. Thanks for the catch!
I’m also posting it with an open-source tag, and do NOT want to receive any grief about that. 😉 I’d rather attach too many tags than too few.
Thanks!
CAM