Attempting to spin up to speed on BackdropCMS and understand structure and limitations with exit strategy in mind at start line.
I am leery of adding fields to USER table as an update to that table would likely queer the whole site. So, relational database design would suggest a user created table linked back to USER table via each User's primary key ID.
I was hoping that would be the outcome of the "PROFILE" module. Nope...
With PROFILE module, one can create multiple "profile blocks" of info, to wit my thinking; Contact (firstname, last name, phone1, phone2, phone3, emaila, emailb), OCCUPATION, INTERESTS, ETC. So, using the "add field" in profile area of backdrop, I added "First Name" and "Last Name" as fields. Reviewing the database via phpmyadmin, the result is two additional tables for each field;
and each of these tables (1 table per profile field added) has multiple fields. Apparently, each of these fields is an entity, with entity ID, etc.
Bottom-line, the concept of a "profile table" and "profile fields" to extend user details/specificity is good, but terrible in practice. Each additional field added in this manner adds 2 tables and 12-16 database fields instead of one. It may be effective "hack" for a single field add, but 50 fields is a disaster. Under the backdrop profile "default" customization method, it virtually will be impossible to import client data as the fields are spread over so many tables each with their own set of keys etc.
Again, it would make much more sense to;
- establish a "user_profile" table, linked via user table's primary key
- extend user detail specificity/fields
- USER table then has primary key, uid, password, email
- USER_PROFILE table then has additional detail fields desired
User importation would then be;
- importation of uid/pass/email (auto increment on import)... adding of two fields to any database list of clients (uid/pass)
- once the User table is populated via import... grab primary key and add that field to database
- import entire database to the user_profile table
Under the backdrop "default", it virtually will be impossible to import client data as the fields are spread over so many tables each with their own set of keys etc.
Certainly someone has considered or encountered this before.. I'll help design improvement to simplify this but I'm wondering if this is attempt to make a square wheel round???
Thoughts and or direction on underlying functionality issues preventing this appreciated.