Зберігати профіль користувача та користувача в різних таблицях?

У кількох проектах я бачив, що розробники вважають за краще зберігати основну інформацію про користувача в одній таблиці (електронна пошта / логін, хеш паролів, ім'я екрана) та решту несуттєвого профілю користувача в іншій (дата створення, країна тощо). Я маю на увазі, що ці дані потрібні лише зрідка. Очевидною перевагою є те, що якщо ви використовуєте запит на ORM менше полів, очевидно, це добре. Але тоді ви можете мати два об'єкти, відображені в одній таблиці, і це позбавить вас від запитів, які вам не потрібні (при цьому зручніше). Хтось знає якусь іншу перевагу зберігання цих речей у двох таблицях?

Це залежить від розміру та вимог вашого проекту.

Я бачу один спосіб, за яким дані про користувачів можна розділити на два набори з різною метою та, таким чином, вимогами:

• Дані про особу: ім’я користувача, хеш пароля, електронна адреса, час останнього входу тощо.
• Дані профілю користувача, які включають налаштування користувачів, останню активність, оновлення статусу тощо.

Зауважте, що щодо користувача є деякі атрибути, які можуть потрапляти в будь-яку категорію (наприклад, дата народження користувача). Відмінність цих двох наборів полягає в тому, що перший жорстко контролюється, і лише за допомогою певних робочих процесів його можна змінювати. Наприклад, зміна пароля може зажадати введення існуючого пароля, зміна електронної пошти може зажадати підтвердження електронної пошти, і воно буде використовуватися у випадку, якщо користувач забуде пароль.

Налаштування не вимагають таких ACL, і теоретично вони можуть бути змінені користувачем або іншим додатком до тих пір, поки користувач погодиться на нього. Заходи низькі, якщо програма зловмисно або через помилку пошкоджує дані або намагається їх змінити (припускаючи інші заходи безпеки.) Однак, це, як правило, катастрофічно, якщо будь-яке ім'я користувача, пароль або електронну пошту можна змінити оскільки вони можуть бути використані для присвоєння особі користувача або відмови в обслуговуванні, або викликають витрати на підтримку тощо.

Таким чином, зазвичай дані зберігаються в двох типах систем:

• Дані про особистість зазвичай містяться в каталозі або в рішенні IAM.
• Дані про налаштування опиняться в базі даних.

Сказавши, що на практиці люди будуть порушувати ці правила та використовувати ті чи інші (наприклад, SQL-сервер, що стоїть за провайдером членства в ASP.NET).

Коли дані про особистість стають більшими, або організація, яка їх використовує, збільшується, виникають різні типи проблем. Наприклад, у випадку каталогу він спробує негайно повторити зміни пароля на всіх серверах у середовищі з декількома серверами. Однак переваги користувачів вимагають лише можливої ​​послідовності. (FYI: Обидва це різні оптимізації теореми CAPS.)

Нарешті, каталоги (наприклад, онлайн / хмарні каталоги) також видаватимуть маркери доступу для інших ресурсів за допомогою таких протоколів, як OAUTH (наприклад, Facebook, Google, обліковий запис Microsoft, ADFS), тоді як база даних не потребує такої потреби. База даних підтримуватиме досить складну структуру приєднань та запитів, якій каталог не потрібен.

Для отримання більш детальної інформації допоможе кілька пошуків у каталозі ідентифікаційних даних проти бази даних.

Врешті-решт, це зводиться до того, якими є ваші сценарії та очікуються у майбутньому, включаючи інтеграцію з будь-якими третіми сторонами (і що вони використовують). Якщо це добре вміщений проект, і ви впевнені, що можете захистити дані ідентифікації користувача та правильно засвідчити автентифікацію, тоді ви можете перейти до бази даних. В іншому випадку, можливо, варто вивчити каталог посвідчень.

Якщо ви перейдете до DB, IMO, використання однієї БД проти двох з часом призведе до контролю доступу, як для користувачів, так і для додатків.

Принаймні, є три випадки, коли мати таблицю людини для основних атрибутів та другу таблицю для інших атрибутів, що мають відношення один до одного, бажано:

• Дані BLOB як зображення. Окрема таблиця дозволяє зберігати дані окремо з міркувань продуктивності, наприклад, в окремому просторі таблиць.
• Дані, які не стосуються всіх або стосуються лише людини, яка грає певну роль. Подумайте про це як стовпці, які були б нульовими у багатьох рядках, якби вони були частиною головної таблиці. У базі даних клініки ви можете мати таблицю людей, таблицю пацієнтів та таблицю медиків, у першій ви маєте основні ознаки, у другій - лише атрибути, що стосуються відповідних випадків, коли людина є пацієнтом, як страхове покриття, в третій таблиці (коли людина є медиком) ви могли б мати медико-спеціальні та інші дані, які стосуються лише медичного персоналу. Очевидно, медик може бути пацієнтом.
• Таблиця, яка матеріалізує відносини з сутністю у віддаленій системі. У цьому випадку таблиця встановлює еквівалентність між унікальними ідентифікаторами в окремій базі даних з міркувань сумісності.

Я думаю, випадок, який ви викриєте, підпадає під другий випадок.

Моя головна причина, щоб вони не були відокремленими, - це намагатися уникати того, що відомо в об'єктно-орієнтованому програмуванні як «клас богів». Таблиці та поля ORM відносять до класів та атрибутів, тому вони стають доречними і на рівні SQL (навіть без ORM існує схожий принцип при грі).

Клас User (і за асоціацією користувальницької таблиці) часто є таблицею, яка стає класом God із сотнею атрибутів / полів, десятками чи сотнями методів та визначенням класу (для методів) понад 1000 рядків. Я це все бачив. Більше одного разу.

Тож відокремлення від користувача намагається вирішити це. Можливо, особа, користувач, обліковий запис і розділення проблем можуть здатися трохи штучними, але варто намагатися уникати складності та гарантувати, що кожен об’єкт стосується лише одного аспекту даних.