RE: Liferay DB

RE: Data model documentation?

2011-03-03T18:42:31Z

I love how Grails uses Hibernate to add foreign keys to the application databases. I can look at the databases and immediately see the relationships between the data. If Liferay can let Hibernate do the work, can Hibernate add the foreign keys that 1) make ERD tools useful and 2) declaratively enforce referential constraints?

RE: Where are the foreign keys?

2011-03-03T18:36:24Z

Nope. There are no foreign keys. Relationships are only enforced in Java.

RE: Liferay DB

2011-02-22T02:33:18Z

There is a final advantage to adding foreign key constraints. The act of adding the constraint uses the database engine to validate the existing design. As as experiment (that I would never do in production), I generated a list of about 300 foreign keys from some assumptions that I made about the database naming conventions. I may well be wrong in my assumpions, but I added over 300 foreign keys with only 4 errors.

For example, I tried to add the following foreign key in PostgreSQL:

alter table portletitem add constraint fk_portletitem_portlet foreign key (portletid) references portlet(portletid) on delete cascade;

The database engine returns an error and reports that there is no unique constraint on portletid in the portlet table. Unlike most tables, the portlet table has an id named id_ that is used as the primary key. Most of the time, the table and the column have similar names, like phone and phoneid. Other tables that appear to reference the portal table all use a column named portalid, which is a varchar(75). In the portlet table, the column portletid is a varchar(200). I have not looked into this in detail, but I will bet that bad things could happen if two porlets share a common portalstringid. I'll also bet that all of the portletid columns reference the same strings. So I will argue that they should all be varchar(200) or they all should be varchar(75), depending upon the maximum length of a portletid. These are very picky criticisms, but I will also bet that they are correct.

RE: Liferay DB

2011-02-21T18:47:45Z

In order for your referenced code example to replicate a foreign key, there should be a transaction that rolls back in the event that either delete fails. For me, any database interaction should be ACID (atomic, consistent, isolated and durable). In my opinion, this code example actually strengths the case that a foreign key should be used. The two delete statements use seperate group.getGroupId() to determine which records to delete. Is it not possible that the two calls will return different values and result in invalid references? There are other concurrent users and on rare occasions, function calls error on the JVM.

RE: Liferay DB

2011-02-22T00:54:41Z

One of the challenges that I face with any portal is the separation of 'enterprise' and 'application' data. The lportal holds a great deal of data that is strategic to the company hosting it. But the lportal is clearly an 'application database'. The companies, users and so on of the community members are the same people and organizations that are found in the existing 'enterprise database'.

This requires at the very least some ETL (extract, transform, load) process to gather data from the portal and push it to the enterprise database. It should probably also have some process to monitor the enterprise database for data changes that need to to added, manually perhaps by a administrator, to the portal. If Jane Maidenname gets married and changes her her name to Jane Husbandsname, then that needs to be reflected in both company records (HR) and in her portal records. (Her user_ records).

I would like to be able to do this with tools like Pentaho's PDI. It would be a big plus to me if lportal had explicit foreign keys. One of features that I really like about (Groovy on) Grails, is that it generates foreign keys in its ORM, so there is a precedent for an ORM that adds foreign keys explicity. From the column names, it seems that there are at least 360 implied foreign keys in the lportal database. (based on queries of information_schema in the postgresql implmentation) If these were explicit, then I could see them in any ERD tool. This would really help in creating the ETL processes.

I also use the density of foreign keys (ratio of keys to tables in the database) as a tool to estimate the quality of a database design. It has been my experience that this is a pretty good measure. But in the case of Liferay, I get a score of zero which is not all all indicative of the (very good) database design.

There are cases where 'redundant' foreign keys are seen as performance limiting. Then they are intentionally omitted as an optimization. If that is the case, can we at least have the option to choose data validation over performance? If the foreign keys are added with ' on deleted cascade', there is almost no risk of the foreign key somehow interfering with the normal operation of the Java application.