Your articles are represented in perl as objects, i.e. blessed hashes. These inherit from a class of objects called a 'node'. You want to store all these objects persistently, and you choose a relational database to do so. You create a table called 'node', do you have a field called 'modified' to store the time that the 'node' was 'changed'? What if you have thousands of rows in the table and the most common value for the modified field is 'NULL'. Aren't you now breaching First Normal Form? Should you rethink your design?Well, whether 'NULL' is allowed in 1NF is controversial. The page you link to actually points this out.
However, there's no reason you should have NULLs in your database. Given that you chose to use a relation database to store your data, it does not mean any object should map to a single row, using a column for each possible attribute. Such a mapping is of course the most trivial to implement (and often seen), but it doesn't do justice to the relation database, and you aren't likely to end up with a structure that's in any normal form. You may as well use DB_File or YAML to do your persistent storage.
But using an appropriate mapper between your objects and your database can give a good database structure. It may mean extra work though.
In reply to Re: So, what's an object attribute anyway?
by JavaFan
in thread So, what's an object attribute anyway?
by Nomad
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |