Разделяне на таблица потребители от таблица хора в релационна база данни

Това със сигурност е добра идея, тъй като нормализирате базата данни. Направих подобен дизайн в приложение, което пиша, където имам таблица за служители и таблица за потребители. Потребителите може да са от външна компания или служител, така че имам отделни таблици, защото служителят винаги е потребител, но потребителят може да не е служител.

Проблемите, с които ще се сблъскате, са, че винаги когато използвате таблицата с потребители, почти винаги ще искате таблицата с хора да получи името или други общи атрибути, които бихте искали да се показват.

От гледна точка на кодирането, ако използвате чист SQL, ще са необходими малко повече усилия, за да анализирате мислено оператора select. Може да е малко по-сложно, ако използвате ORM библиотека. Нямам достатъчно опит с тях.

В моето приложение го пиша в Ruby on Rails, така че постоянно правя неща като Emploee.user.name, където, ако ги държа заедно, ще бъде просто Emploee.name или user.name.

От гледна точка на ефективността, вие удряте две маси вместо една, но при правилни индекси, това трябва да е незначително. Ако имате индекс, който съдържа първичния ключ и името на лицето, например, базата данни ще удари потребителската таблица, след това индексът за таблицата с лица (с почти директно попадение), така че производителността ще бъде почти същата като с една маса.

Можете също така да създадете изглед в базата данни, за да запазите двете таблици свързани заедно, за да ви дадат допълнителни подобрения на производителността. Знам, че в по-късните версии на Oracle можете дори да поставите индекс на изглед, ако е необходимо, за да увеличите производителността.

Правя това редовно, защото за мен понятието „потребител“ (потребителско име, парола, дата на създаване, последна дата на влизане) е различно от „лице“ (име, адрес, телефон, имейл). Един от недостатъците, които може да откриете, е, че вашите заявки често ще изискват повече присъединявания, за да получите информацията, която търсите. Ако всичко, което имате, е име за вход, ще трябва да се присъедините към таблицата „хора“, за да получите например първото и фамилното име. Ако базирате всичко около първичния ключ на потребителския идентификатор, това се смекчава малко, но все пак изскача.

Ако user_tb има информация за удостоверяване, много бих я запазил отделно от people_tb. Въпреки това бих запазил връзка между двете и по-голямата част от информацията на потребителите ще се съхранява в people_tb, с изключение на цялата информация, необходима за удостоверяване (която предполагам няма да се използва за много други неща) Това е добър компромис между дизайн и ефективност мисля.

Това определено правим, тъй като имаме записи на милиони хора и само хиляди потребители. Ние също разделяме адреси, телефони и имейли в релационни таблици, тъй като много хора имат повече от едно от всяко от тези неща. Важно е да не разчитате на име, тъй като идентификаторът като име не е уникален. Уверете се, че таблиците са свързани чрез някакъв тип сурогатен ключ (за предпочитане е цяло число или GUID), а не име.

Бих казал, че отидете на нормализирания дизайн (две таблици) и денормализирайте само (слезте до една таблица потребител/човек), ако това наистина ще улесни живота ви в крайна сметка. Ако обаче практически всички хора са и потребители, може да е по-лесно да денормализирате предварително. От теб зависи; Използвах нормализирания подход без проблеми.

Много разумно.

Като пример, разгледайте таблиците на услугите aspnet_* тук.

Тяхната вградена схема има aspnet_Users и aspnet_Membership, като по-късната таблица има по-разширена информация за даден потребител (хеширани пароли и т.н.), но aspnet_User.UserID се използва в другите части на схемата за референтна цялост и т.н.

В крайна сметка, много обичайно и с добър дизайн е да има атрибути в отделна таблица, ако са различни обекти, както във вашия случай.

Винаги се опитвам да избягвам възможно най-много повторения на данни. Ако не всички хора трябва да влизат, можете да имате обща people таблица с информацията, която се отнася както за хората, така и за потребителите (напр. име, фамилия и т.н.).

След това за хора, които влизат, можете да имате таблица users, която има връзка 1~1 с people. Тази таблица може да съхранява потребителското име и паролата.