I will have a scheduled task to do data cleanup. I just don't like the idea of mixing the demo data with the live data. I guess the same can be said of the app itself but the data seems most important to me.
The app has a calendar section and it's that section that I'm thinking of. Calendars demo better when they appear "full" so each night I'll drop and rebuild +/- 45 days from "today" worth of data. Demo users can then do with as they please. This might represent 200 rows total among various tables. Not a lot but I really like the idea of keeping demo data separate. The idea, then, is 3 datasources. DSN1 contains ALL user login data and is used to log all users in and out. DSN2a has the users' calendar/app data. I suppose in the future there could be DSN2b, DSN2c,... and so forth if decided to keep individual database size small. DSN2z, then, would be solely for demo user data. I realize I'm opening myself up to getting laughed at with the multiple datasource needs based on imaginary future customers but my primary competitor has 40,000 subscribers who use their logins at least weekly. I'm just trying to figure out the "cleanest" way to do the above. Thanks! -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
