Мне действительно нужны индивидуальные таблицы для моих трех типов пользователей?

Question

Мне действительно нужны индивидуальные таблицы для моих трех типов пользователей?

Я хотел бы добавить для полноты, что вы также можете добавить только БИБЛИОТЕЧНУЮ ПУТЬ, где он будет искать зависимую библиотеку (которая не может быть напрямую указана в вашем коде, но вам может понадобиться библиотека, которую вы используете).

Для сравнения это соответствовало бы тому, что делает среда LIBPATH, но ее вид неясен в Qt Creator и недостаточно хорошо документирован.

Как я это сделал:

LIBS += -L"$$_PRO_FILE_PWD_/Path_to_Psapi_lib/"

По сути, если вы не указали фактическое имя библиотеки, оно добавляет путь к тому, где он будет искать библиотеки, зависящие от поиска. Разница в синтаксисе небольшая, но это очень полезно для предоставления только PATH, где искать зависимые библиотеки. Это когда-то просто боль, чтобы предоставить каждому пути отдельную библиотеку, где вы знаете, что все они в определенной папке, и Qt Creator подберет их.

0

postgresql database-design

задан a_horse_with_no_name 8 March 2019 в 09:50

2 ответа

Другие вопросы по тегам:

postgresql database-design

Похожие вопросы:

score 0 · Answer 1

Похоже, что это случай попытки моделировать наследование в вашей реляционной базе данных. Сложная тема, обсуждаемая здесь здесь и здесь .

Это звучит , как будто вашему «продавцу, потребителю, продавцу» понадобится много разных атрибутов и отношений. Продавец обычно принадлежит к отделу, имеет цели, связан с продажами. У потребителя есть история покупок, возможно, кредитный лимит и т. Д.

Если это так, я бы предположил, что «наследование таблиц классов» может быть правильным решением.

Это может выглядеть примерно так.

create table user_account
(id int not null, 
username varchar not null, 
password varchar not null
....);

create table buyer
(id int not null, 
user_account_id int not null(fk), 
credit_limit float not null, 
....);

create table seller
(id int not null, 
user_account_id int not null(fk),
sales_target float,
....);

Чтобы ответить на ваш другой вопрос - реляционные базы данных оптимизированы для объединения таблиц. Десятилетия исследований и разработок ушли в эту область, и хорошо спроектированная база данных (с индексами по столбцам, к которым вы присоединяетесь) не будет оказывать заметного влияния на производительность из-за объединений. Из практического опыта запросы с сотнями миллионов записей и десятью или более объединениями выполняются очень быстро на современном оборудовании.

score 0 · Answer 2

Если роль только , которая отличает этих людей, это роль, но все детали одинаковы, то я бы определенно выбрал одну таблицу.

Вопрос, однако, может ли один человек иметь более чем одну роль? Если это не так, добавьте столбец role_type в таблицу person. В зависимости от того, насколько фиксированы эти роли, возможно, используйте справочную таблицу и внешний ключ, например:

create table role_type
(
   id integer primary key,
   name varchar(20) not null unique
);

create table person
(
  id integer primary key, 
  .... other attributes ..., 
  role_id integer not null references role_type
);

Однако, по моему опыту, ограничение ровно одной роли на человека обычно не выполняется, так что вы бы нужен корабль связи «многие ко многим»

create table role_type
(
   id integer primary key,
   name varchar(20) not null unique
);

create table person
(
  id integer primary key, 
  .... other attributes ..., 
);

create table person_role
(
  person_id integer not null references person, 
  role_id integer not null references role_type, 
  primary key (person_id, role_id)
);