First, thanks a lot for your DMZ library! I've read the documentation (several times) and still laughing when I see how easy it is to accomplish some complicated tasks/queries with DMZ.
Second, good luck and best wishes on your ZestyJobs project. I'm running a local membership site, and interested in global SaaS projects - and yours is very promising. I hope your project will be featured on FreelanceSwitch, WebWorkerDaily and maybe on Lifehacker - or on other related blogs which have lots of visitors.
Humble Idea: You may want to run a blog for ZJ because when I decide on whether or not use be a premium/paid member of a SaaS, I always check their blog and see how often they update their service. (A good indication on whether the entrepreneur is still working on the project or not.)
Third, I need a point of view on database design - which supports DMZ:
My project is a niche classifieds site, and the table names goes like this:
* Table names that start with "constants_" prefix keep the required data which is related to the profiles in some ways. (For example, "constants_lessons" has columns like id, name, keyword, description, language, synonyms, order, etc.)
* Table names that start with "profiles_" prefix keep the users' (either individual or group) profile data. (For example, "profiles_lessons" has columns like id, lesson_id, user_id, price, experience, etc.)
So, profiles_ tables are more than a join table because each user may have many lessons in his/her profile - and they can declare a price and experience year (and other details) for each lesson that they are listing on their profile... and they can change the order of each lesson on their profile - based on their priorities.
My questions are:
1) What will be the proper way of designing tables, and join tables (if needed?)
2) And how should I name Models - considering the fact that I'm planning to use table names like "profiles_lessons" and "constants_lessons"? (e.g. Should the "Lesson" model - with relevant "var $prefix" - cover "constants_" or "profiles_"?)
The questions above may all be wrong - if the database design that I'm planning is wrong in the first place... but looking forward to the ideas who are more experienced and smarter than me on solving this database design problem.
Thanks!
------------------------------
UPDATE: I know that with small tweaks, I can convert "profiles_lessons" to a join table like "join_lessons_profiles" and use "include_join_fields", "_join_field", "set_join_field" BUT I need to do a lot of SORT BY operations with those join_fields (experience, price and order) and using _join_field does not sound like the most efficient way to me.
