hbaxmann: anonymous wrote : solution: build a db view per optional field, null-'key' rows will vanish, not the denormalized table
This isn't a relational issue. The query I mentioned with 4 columns ironically has no relationships whatsoever. However, it does have 4 optional columns I need to filter on. They happen to be parts of a business key, but that's arbitrary. They could be any optional column that I need to filter on. Remember, this issue is I'm passing a parameter and pulling values that match that paramter. This isn't complext, and has nothing to do with normalization because it has nothing to do with joins or relationships. anonymous wrote : if your app rely on more then one _significant_ optional field - your ER model sucks Huh?!? More than half a table's columns are often optional. Any column can be filtered via a parameterized where clause in the real world. These are common business requirements. Just because a customer table does require an email address doesn't mean the user shouldn't be able to query based on the email address. Just because an email address is optional doesn't mean that every other piece of customer information has to be mandatory. How is having multiple optional columns a bad model? anonymous wrote : And your query, even implemented in SQL, is 100% compatible with all the databases because SQL address the database compatibility before java and J2EE. Wouldn't that be nice if it were true. To name a few differences: the formatting of a date in the where clause, unique identifier generators and the syntax of outter joins. I wrote one system that ran in both SQL Server and Oracle. Last year, I lead the migration of a J2EE application to use a new DB2 data model with 150+ tables while still working 100% with its Oracle 90+ table predecessor. To complicate things, we had to use stored procedures for all data communication for DB2 (dumb "security" standard .) The calculation code, which never stopped being fully functional during the entire migration, was 100% independent of the database vendor, but it it wasn't SQL that made it possible. We used a Data Accessor pattern. There are two two problems with SQL: The ANSI 89 and 92 standards that became popular did not address all the needs (e.g., dates in the WHERE clause). The second problem is that it is relational, making it difficult to migrate to object database technologies. Thus... CMP, and the current trend of using object-relational to implement it. If Sun's Java certification has anything that requires CMP to use a relational database, then they are not testing the standard, because nothing in the standard requires a relational database for implementation. If they relational database requirements have drifted into it, then it's probably just because every vendor out there implemented it with a relational model. Thus, when vendors start to implement it with object databases as well, Sun will be obligated to remove any relational specific requirements that slipped into their test suite. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3836352#3836352 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3836352 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
