Best Practise structure for sports2000 - OpenEdge Installation & Deployment - Products Enhancements - Progress Community

 OpenEdge Installation & Deployment

Best Practise structure for sports2000

I wasn't sure where to put this really, but decided this was the best place. 

Please can the DB structure for sports2000 be enhanced to follow modern best practise for DB administration? So for example, the tables and indexes are grouped by function, but by RPB and data/index. Oh and the storage areas are type I too IIRC. It's a real pet peeve of mine. I've done a couple of "correct" structures over the years, and mine's by no means perfect, but it's a right pain whenever I think of implementing sports2000 to demo something to remember to go to my backup rather than $DLC. 

Thanks :) 

Comments
  • You're right James, sports2000 uses all Type I, contains a default index, an index in the schema area, mixed-use areas, etc.  The sports DB contains a mix of Type I and II areas; so does demo.  

    There are other aspects of the current in-box sample DBs that don't follow contemporary best practices, aside from structure design.  For example, trigger and validation code.  If you're using these DBs to look at CRUD stats you have to be careful as activity on one object can lead to activity on another where you wouldn't expect it if you didn't know about the triggers and validation snippets.  

  • Sports2000 is a disaster. How can an example db not even be properly normalized?

  • Completely agree I'm trying my best to use it for my PUG prep but having an absolute nightmare with it!