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.


This is not a complete answer to what you're discussing above but just to put this out there: I've seen a few comments related to user imports so decided I'd start porting the "User Import" module. if that seems like it might be useful, feel free to jump over there and help with testing and fixes:

drop's picture

@ part of the reason the database table structure in Backdrop is so complex (and yes, we recognize that it is too complex) is that the "fields" on a user profile are exactly the same kind of "fields" that can be added to content, categories, or any other type of entity. This consistency across the whole system means that once someone learns how to manage fields in one place, it will be the same everywhere else. 

These fields can be single or multi-value, can have complex user interfaces, often have numerous configuration options, sometimes have fancy validation, and all while maintaining consistent features like the ability to translate each individual value into multiple languages. All that functionality can lead to a bit of a mess, underneath.

Rather than running direct queries against the database to import user profile records, I recommend you stick to using the API instead. You will probably find creating a new user account, adding data to the user account, and saving the user account, much simpler than querying the database directly. Let Backdrop worry about that messy structure underneath, and use the handy tools it provides for you :)