When you go to information programming the rules change
There is a different set of best practices.
- Use more tables in your object oriented programming, use fewer tables in the database. Make information generic tables. Use less members. Use more generic classes.
- Use endeme activated members.
- Avoid inheritance.
- Use the db sparingly for info tables and include heavy amounts of overhead code to manage them.
- Avoid stored procedures. Use them only to build your information table framework.
- Use dynamic construction of sql inside OO.
- Include a dynamic sql framework to cover sql injection.
- Often use GUIDs and single letter codes rather than integers for keys.
Information programming is different from data programming.
Many of the rules of data programming are based on trying to make sure that people do not use information programming techniques while doing data programming. You see, untrained people writing programs have an intuition that includes both data in and information programming. So they tend to mix techniques when programming. Using information techniques when doing data programming has significant problems. Codes, Dynamic SQL, constructed indexes, 0NF, mixing data and presentation, building tables with information attributes, all sorts of ‘bad’ programming practices. So people get trained to not use information oriented techniques while programming. However these techniques are appropriate when doing information programming.
This distinction shows up especially when you are doing low level information oriented programming because it is similar to object oriented programming. You just need to know which you are doing at any given time.