AppGini Community Forums

Hi,

I have been working with AG and have a design question issue. I have a database that will serve 10 companies.

1. Each company will need to have credentials with complete"ownership and filtering" of all data entered uniquely to their "operations"
2. I understand that I can have a common database and create each record in each table with key that identifies "who" owns the record in the tables and are there AG examples of this approach?
3. The clarity I need is does appgini membeship allow for this type of "separation\ownership" of records completely using membership for admin, creators, editor, and reviewers of this data using groups or owners?
4. Performance is the next issue; If I have 10 companies creating, editing, uploading pdfs, in this environment is appgini capable of "scaling" or "stabilizng" read/writes to the database?
5. What if it grows to 100 companies with 5 users each hitting the same database with "different" and "Unique" ownership the record in a database?
6. My basic question is should I just have a separate database for each company or should I approach it with a universal database and have each company "own" their data in a common database?
7. Are there samples or white paper on how to handle such a scenario in Appgini.
8. for the record.. I am adding to each table company_id, location_id, and unique_key to each table that no matter what each record will be retrievable.
9. from what I read, I would need to "filter" each view by company_id, location_id, unique_key in addition to the user "owndership" to insure proper workflow and usage.
10. is there a better approach or suggestion for this scenario utilizing the AG system.
11. I love what I have been able to accomplish; this is by far the fastest application design and generator I have ever used. Very Nice!
12. Thank you in advance

Sincerely,

Dmac411

Most of your problems are server related and not about coding nor appgini, get a powerfull server and you should have no problem.

The rest can be solved by using one database per company.

One database per company is a lot better anyway:
If you have one database for all and something goes wrong, EVERYONE will be in trouble.
One database per compay and one of them goes wrong, Only ONE company will be in trouble.
Of course you should be planing a very good solution for backup if you have so many companys like this on the same server.

Do you have consolidated reporting requirements? I agree one db per company is a good approach but also your idea of still including company_id in your tables is a great idea. If you do that and have one db per company you can still run a consolidation process to pull data from all dbs into a readonly reporting db etc.

Fellow Appginians,

Thank you for your advice; I am going to approach this project with one database per company AND have a consolidation database for reporting as suggested.
I am going to also have a "master" database in which I can consolidate data for redundancy and document management. There will be document uploads from each company and my thoughts are to
reduce load by having specific servers dedicated to serving document retrieval and review.

Based on your suggestions, I researched "multi-tenancy databases" and your suggested approach seems the most feasible.

Obviously, I want to have one code base serve all companies and may consider looking at single sign code for integrating with the Appgini code base so that each company can be directed to their db based on their credentials (I don't think there are hooks for this.. yet) but I'm certain there will be in the future. I have seen the product mature nicely for at least 6 years.

Thank you so much for taking the time; it was very helpful

Dmac411

Sounds like you have an exciting project with some real world applications. Would love to learn from your experiences so please do let us know how you go and learnings along the way. Good luck!

Thank You, Ksan - I have been busy coding productively with this great tool and am excited about the application. I have made lots of progress.