In a heterogeneous language environment (Java, Ruby and Coffeescript where I am), defining types in the application doesn't give sufficient coverage because not

In a heterogeneous language environment (Java, Ruby and Coffeescript where I am), defining types in the application doesn't give sufficient coverage because not all languages are statically typed. Referential integrity is important, but sometimes has to be sacrificed for performance reasons (ideally foreign keys are only temporarily disabled for bulk actions). Other column-level constraints are nice to have but less critical. For the kind of work we do at my company - involving bulk upload, bulk inserts, bulk joins - thinking relationally is much more productive than thinking in objects, and really fast key-based lookups are far less important than really fast joins. Only configuration data lives in objects; other data is served up using a lightweight translation of the result set to JSON, with no business entity intermediary; one of the primary reasons being that the user gets to define their own schema, so any object would have a variable number of fields and types anyway. Writing the same logic in different places is definitely a problem; you want to avoid that. We've taken to putting some logic in JRuby just to be able to use the same source in Rails and Java. For other logic, we have a Java service API endpoint that Rails can call. For maintenance purposes, it's really worthwhile not duplicating very complex logic in multiple places. Relational databases - or rather, relational algebra, even if computed over something like Spark or Impala - is, to me, worth far more than something more suited for storing objects. Thinking in terms of relations is just more productive for efficient code than navigating object graphs.