Level 7
"1000 tables" Wow!
Is this a SaaS solution? Does the client sign-up online or do you deploy your solution on a client-by-client basis?
1 like
Feb 10, 2019
10
Level 32
Need advice for developing an ERP
Hi All, I have developed an ERP software written in pure PHP with 22 different modules such as Accounting, HR, CRM, Warehouse, Transport ..etc. Also it contain nearly 1000 tables. Same application used by multiple customers.
I plan to re-write this application using laravel. I would like to get advice from you all about how do I structure this and what are the best practices. I have multiple customers using the same application what is the best approach to start developments? The current application contains many features but this level I consider following points:
1. Multiple Modules (Accounting, HR, CRM, Repoting, Transport ...etc all modules are linked with finance)
2. Multiple Customers with different configurations (Separate Database for each, On/Off switches for features)
Level 32
Correct its Saas, but client can registered only once they signed the agreements. Do you have any idea how to do this?
Level 7
Well, if you plan on replacing your existing solution with another monolithic application I would namespace your modules for example;
/accounting
/hr
/crm
etc ...
and where possible package up your features.
Alternatively, take a peek at the responses I gave on this thread for a different approach.
https://laracasts.com/discuss/channels/laravel/web-vs-api-on-a-project
1 like
Level 32
I thought the same way.. What about multiple customers, (One customer have many users + admins + on/off features) They need separate Databases.
Level 15
Probably a rethink of the entity relationships and modelling in the system. A customer is an entity - or rather looks like an entity. They may be different - say customer types etc - but more tables can be added to take care of the difference. Say a customer_types table that has types such as corporate, premium,individual ...etc. On/off features would be tied to either companys / clients / customer - so you could have a features table, and a company_feature table having id,company_id,feature_id, state. where the state could be on and off.
Personally I would use 1 database and focus more on entity relationship modelling.
Level 32
@douglasakula My domain for application is logistics.. Imagine one table contain millions of records and and more than 300 customers. Millions X 300 so, you think one database can handle?
Level 20
Not from a technical point of view, but for selling... It could be a good argument to say that each customer have is own database, and that information will never cross one of a competitor.
1 like
Level 15
@nalindadj @vilfago Ok that makes sense then - Was thinking SAAS - Each customer having their own database would make sense in this case.
Would the database be 1 structure or you foresee a situation where different cuustomers would require features that necessitate changes in their database ?
The way I would have preferred then is 1 database structure and features can be on/off where specific customer don't need certain features or are not paying for them - Sounds easier to maintain
Or probably modular so each module comes with a set of tables
1 like
Level 11
@NALINDADJ - Consider a multi-tenant solution, like this one: https://github.com/hyn/multi-tenant
Level 32
@douglasakula Yes.. currently also it same. I maintain same database structure for all my clients. I have written my own program to do changes on all database at once. Not only that but also current application support for different countries as well. Everything controlled by on/off switches. Fortunately workflow for the industry is same among all the costumer even in different countries, even-though some customers have different approaches I'm bringing them to the best practices.
1 like
Please or to participate in this conversation.