в данном конкретном случае я бы предложил 2 варианта:
1 таблица подразделений института с деревянной структурой где сам институт будет корнем
2 таблица параметров общего вида для всей БД, где будет несколько записей с названием, адресом и т.п.
таблица с единственной записью выглядит неестественно
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не понял. Речь шла о хранении в БД и связях, при чем тут view ? Если в ней данные не будут меняться, то почему бы не использовать вьюху и с ней уже работать как с таблицей?
Сорян, проморгал, что данные могут править.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Stanislaw K, Вы писали:
PD>Я не понимаю, к чему все это. То, что версионность может понадобиться, я не спорю. Вопрос же не в этом, а в том, как быть, если запись именно одна. PD>Если для этого варианта есть соображения — готов их выслушать, а уходить в сторону не буду.
Нет ни чего более не логичней, чем бизнес-логика, "выпрямлять" ее не всегда нужно, а по мне не нужно вообще. Это обычный инвариант, за соблюдение которого отвечает бд.
Здравствуйте, VsevolodC, Вы писали:
VC>1 таблица подразделений института с деревянной структурой где сам институт будет корнем VC>2 таблица параметров общего вида для всей БД, где будет несколько записей с названием, адресом и т.п.
VC>таблица с единственной записью выглядит неестественно
Cогласен, что неестественно, но не очень естественна и ситуация, когда есть таблицы факультетов, групп и т.д., а таблицы института нет, а вместо нее какая-то таблица общего вида...
В качестве бреда, опять же, с вьюхой. Если в ней сделать выборку только одной строки, например по ид, то сколько бы они не вставляли, то всегда будет возвращаться только выбранная. И значения будут меняться только в выбранной, если они, конечно, не полезут менять саму таблицу. Нет?
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, rFLY, Вы писали:
FLY>В качестве бреда, опять же, с вьюхой. Если в ней сделать выборку только одной строки, например по ид, то сколько бы они не вставляли, то всегда будет возвращаться только выбранная. И значения будут меняться только в выбранной, если они, конечно, не полезут менять саму таблицу. Нет?
Вьюха это select. Чтобы поменять данные тебе нужен доступ до таблицы которая под ней.
Здравствуйте, Qt-Coder, Вы писали:
QC>Вьюха это select. Чтобы поменять данные тебе нужен доступ до таблицы которая под ней.
Апдейт вьюхи апдейтит таблицу, которую она использует в качестве источника.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Cогласен, что неестественно, но не очень естественна и ситуация, когда есть таблицы факультетов, групп и т.д., а таблицы института нет, а вместо нее какая-то таблица общего вида...
Забей. Надо -- делай. Встречал такое не раз.
Как ограничить количество записей уже ответили.
Единственное, стоит ли всегда join'ить эту таблицу с другими, или сделать один раз select и запомнить значения полей в приложении?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В некоторой таблице должна быть одна и только одна запись. PD>Например, table institute — запись об институте, название, адрес, реквизиты и т.д. PD>Поскольку речь идет о БД данного института, запись должна быть одна и только одна.
Нормальный вариант с одной строкой.
Иначе как сделать запрос "Выведи список студентов, живущих на одной улице с институтом"?
Технологической проблемы нет.
Выходит, это чисто психологическая проблема (принятия нежелательного).
Предлагаю, минуя стадии отрицания, гнева, торга и депрессии, перейти сразу к принятию (факта ненужности FK)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Есть ли какая-то best practice для такого случая :
PD>В некоторой таблице должна быть одна и только одна запись.
PD>Например, table institute — запись об институте, название, адрес, реквизиты и т.д. PD>Поскольку речь идет о БД данного института, запись должна быть одна и только одна.
PD>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д.
PD>Но эти FK всегда ссылаются на одну и ту же запись в institute, иначе и быть не может. PD>Получается некоторая избыточность. Фактически этот FK есть константа, а зачем тогда он ?
PD>Ну и второй (несколько академический) вопрос. Как запретить создание второй записи в table institute ? Вариант сделать таблицу R/O не годится — первую строку должно быть можно изменять.
Сделай тригер который удалёет всё лишнее
А вообще просто писать в строку по фиксированному id
Здравствуйте, kov_serg, Вы писали:
PD>> Ну и второй (несколько академический) вопрос. PD>> Как запретить создание второй записи в table institute ? PD>> Вариант сделать таблицу R/O не годится — первую строку должно быть можно изменять.
_>Сделай тригер который удалёет всё лишнее
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну и второй (несколько академический) вопрос. Как запретить создание второй записи в table institute ? Вариант сделать таблицу R/O не годится — первую строку должно быть можно изменять. QC>Можно установить check constraint QC>CREATE TABLE Persons ( QC> ID int NOT NULL, QC> LastName varchar(255) NOT NULL, QC> FirstName varchar(255), QC> Age int, QC> City varchar(255), QC> CONSTRAINT CHK_ID CHECK (ID=1) QC>);
QC>Это запретит создавать записи с ID <> 1
Большинство СУБД требуют уникальности от поля, на которое будет потом установлен foreign key.
Поэтому вот так:
CREATE TABLE Institutes(
ID int not null primary key,
Name varchar(255) NOT NULL,
...,
CONSTRAINT CHK_ID CHECK (ID=1)
);
В будущем, когда всё же потребуется обслуживать несколько институтов, достаточно будет дропнуть 1 констрейнт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
