Okay, it's not a real word, but it was prompted by a typo/spelling error in a post in the XE support forum. What structures will put shivers down your spine when you first set eyes on a database schema ?
- There's only half a dozen tables, the largest of which has just three columns similar to 'Entity Id','Attribute Id' and 'Attribute Value'. Every query in this database will include forty-two joins.
- Lots of columns defined as CHAR rather than VARCHAR, all constrained to NOT NULL. A sure sign of a generic product designed to be database-independent.
- Lots of columns names like USERDATA..., USER_DEFINED..... or similar, so the column names give you no idea what the contents are. Normally the sign of a third-party product. You can guarantee that there won't be any practical constraints and that, at some point, the wrong data will find its way into the wrong column.
- Columns defined as VARCHAR2, but with names suggesting they contain dates/numbers or, in conjunction with 'generic names', just data values that are suggestive of dates and numbers. Look forward to a life of invalid date and value errors.
- Spelling mistakes in table, procedure or column names. I once worked with an application that included a table column "proccess_status". A giveaway that some steps are missing from the review process and bound to trip up programs written in languages that don't validate SQL syntax and semantics at compile time.
- select * from user_constraints where constraint_type = 'R' gives no rows selected. No foreign key enforcement, no data integrity, no data found....
- select * from user_constraints where constraint_type in ('P','U') gives no rows selected. Trust me, the application will enforce it. Yeah, right, with the help of the tooth fairy.