I’m a PHP developer, I work mainly with Symfony2 but I’m really interested on developing my next project with meteor!
The main problem I’m having is figuring out how to implement multiple types of accounts in meteor. In Symfony I have a entity (aka table, collection) with the default users fields (password, username, …) and all types of accounts are entities that extends the core account entity and have the specific fields they need. How is the best way to do it on meteor?
The accounts I need are: Company (22 fields in total)
Full address (street, postal code, city, country)
Company information ( name, phone, vat number, images, description, and social links)
Collaborators (created by company to do stuff for the companies)
Collaborators (8 fields in total)
Basic Info (name, contact, images)
Rating
Posts
Users (15 fields in total)
Username
Password
Favorites
Image
Admins
Can be same as user but with roles…
They must sign in with the same form but only users have a registration form, companies are created in backend by the admin and collaborators are added by the companies.
I will try to create a open source project with this implementation to help other users in the future.
I think this would just mean you have custom data in the standard users table from accounts-password.
You can force those four schema types during Accounts creation using this hook.
This way you don’t need four different tables, you have a single collection.
Having like 30+ fields in the same collection (some having nothing to do with others), isn’t that a bit ugly? Maybe that’s just me complicating, but in my head it makes sense to have the account all in their own places (collections).
If there is no “prettier” way, I will try as you said. Thank you for the answer!
Well you could have separate collections for each type. However you will need to use the user collection to manage the logins.
Then you will need two fields to link to the right collection type (company etc…)
You’re going to need to manually join the collection whenever you reference it. To me it would make more sense to have everything in the single collection with dedicated helpers for each user type.
Thinking that each collection item will have its own empty fields is a relational database concept. Mongo it’s not relational, it’s document based. Empty field means no field, from a performance point of view. And each document can have it’s own custom fields.
Goodbye SQL. Welcome human friendly data structures
Hi @sven . I’m implementing a system just similar as what you described. How 's your app now ? What solution did you implement for your multiple type of account system ?
