Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
Dobrij denj. Problema sledusjushaja: Estj tablici Objects i Resources Objects: pk, parent_pk Resource: pk, name pri etom svjazj odin k odnomu po polju "pk" (Objects 1:1 Resources) do ku4i parent_pk v Objects ukazivaet na roditelja (hozjaina). vopros: kakoj napisatj CONSTRAINT v Resources, 4tobi neljzja bilo sozdatj dva Resource s odinakovim imenem u odnogo i togo zhe roditelja, t.e. UNIQUE (Object.parent_pk, Resource.name) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 12:24 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
inimi slovami : vetka odnogo dereva ne mozhet xranitj dva Resource`a s odinakovim imenem. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 12:57 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
можно 1. написать триггер, в котором вызывать исключение при нарушении условий 2. написать ф-ю, с булевым возвратом, и задать ее в чеке. 3. на фига нам уникью - не приложу. и ващще связь 1-1 (в начале конструирования) как правило заводится от большого ума. а не по необходимости. (ибо, при отсутствии индексов на вьюхи, вы огребаете кучку некоторых проблем с выборками). другое дело, если вы строити звизду, паскоку вам не нравится реализованное в ПГ наследование. (или вы чешете себя мыселью о потенциальной переносимости звезды, при непереносимости ПГ-ной) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 13:14 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
Vob4emto tam kakraz zvezda, i PG uzaetsja v svjazke s HIBERNATE`om, a takoj konstraint - sugubo bisness rule. Spasibo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 13:42 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
AndreyBondVob4emto tam kakraz zvezda, i PG uzaetsja v svjazke s HIBERNATE`om, a takoj konstraint - sugubo bisness rule. Spasibo. Нихрена не понимаю на транслите, но так понимаю, нужно вот это? CREATE UNIQUE INDEX "resource_idx_pk_name" ON "resource" USING btree ("pk", "name"); ALTER TABLE "resource" ADD CONSTRAINT "resource_fk_pk" FOREIGN KEY ("pk") REFERENCES "objects"("pk") ON DELETE RESTRICT ON UPDATE NO ACTION NOT DEFERRABLE; Правда необходимо еще одно условие pk и name - NOT NULL. А то констрейнт уникальности не будет работать, если хоть одно из них NULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2006, 05:47 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
Kruchinin PahanНихрена не понимаю на транслите, но так понимаю, нужно вот это? Код: plaintext 1. Правда необходимо еще одно условие pk и name - NOT NULL. А то констрейнт уникальности не будет работать, если хоть одно из них NULL.гыгыгы. pk - первичный ключ обоих таблиц. т.ч. здорово ваше уникью там сработает . Особливо - про требование Not NULL для Primary Key - хорошо пошло. переведу с телепятцкага на обще-доступный. 1. есть таблица узлов дерева категорий (центральная таблица звезды) pk - Праймери, parent_pk - ссылка на вышестоящую категорию. 2. есть одна из таблиц объектов (категорий некоего подвида) - представленных в таблице узлов своими ключами (pk) pk - праймери и для нее. Т.е. связь 1-1. 3. Нужно (не мне, а в задаче), чтобы на _родительской_ (parent_pk) ветке центральной таблы сидело не более 1-го одноименного представителя 2-й таблицы. и тут выходите вы, весь в белом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2006, 11:40 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
4321 Kruchinin PahanНихрена не понимаю на транслите, но так понимаю, нужно вот это? Код: plaintext 1. Правда необходимо еще одно условие pk и name - NOT NULL. А то констрейнт уникальности не будет работать, если хоть одно из них NULL.гыгыгы. pk - первичный ключ обоих таблиц. т.ч. здорово ваше уникью там сработает . Особливо - про требование Not NULL для Primary Key - хорошо пошло. переведу с телепятцкага на обще-доступный. 1. есть таблица узлов дерева категорий (центральная таблица звезды) pk - Праймери, parent_pk - ссылка на вышестоящую категорию. 2. есть одна из таблиц объектов (категорий некоего подвида) - представленных в таблице узлов своими ключами (pk) pk - праймери и для нее. Т.е. связь 1-1. 3. Нужно (не мне, а в задаче), чтобы на _родительской_ (parent_pk) ветке центральной таблы сидело не более 1-го одноименного представителя 2-й таблицы. и тут выходите вы, весь в белом... Теперь внимательно разглядываем CREATE, и учимся если хотя бы не уважать собеседника, так внимательно читать, что предлагается. UNIQUE накладывается отнюдь не на PK, а вовсе на ("pk", "name"). И NOT NULL предлагается навесить и на PK (где оно и так есть), и на NAME, в противном случае значение составного индекса будет NULL и контроль уникальности производиться не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2006, 05:49 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
Kruchinin PahanТеперь внимательно разглядываем CREATE,я к этому вас и призвал . + подумать. (но это вам, как вижу, не удалось) Kruchinin Pahanи учимся если хотя бы не уважать собеседника, так внимательно читать, что предлагается. UNIQUE накладывается отнюдь не на PK, а вовсе на ("pk", "name"). И NOT NULL предлагается навесить и на PK (где оно и так есть), и на NAME, в противном случае значение составного индекса будет NULL и контроль уникальности производиться не будет.а фули уго уважать, если он себя не уважает. ему уже сотый раз объясняют, что нужен уникью на (parent_pk,name) (т.е. на поля 2-х разных таблиц), а он все лезет со своими глупостями (не дав себе труда разобраться, что предлагает именно и только глупость) в т.ч. - и что пытаться обеспечить любое правило вводом уникью на группу полей, содержащую праймери этой же таблицы - чуддизм, а оне тут еще и выеживаюцца. повторяю для особо упертых. наложение уникью на любую группу полей, содержащую пк таблицы не обеспечивает никакого дополнительного ограничения. пк сам ля, без ансам, ля уникальный, т.ч. идите лесом со своими пертензиями к уважению. и будет нулл в нейме, или не будет нулл в нейме - пк таблицы то уникальный. или вы умеете создавать не уникальные пк? если да - поделитесь сакральным. мы, невнимательные, поучимся у вас невозможному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2006, 12:10 |
|
||
|
CONSTRAINT na 2 tablici
|
|||
|---|---|---|---|
|
#18+
4321а фули уго уважать, если он себя не уважает. ему уже сотый раз объясняют, что нужен уникью на (parent_pk,name) (т.е. на поля 2-х разных таблиц), а он все лезет со своими глупостями (не дав себе труда разобраться, что предлагает именно и только глупость) в т.ч. - и что пытаться обеспечить любое правило вводом уникью на группу полей, содержащую праймери этой же таблицы - чуддизм, а оне тут еще и выеживаюцца. повторяю для особо упертых. наложение уникью на любую группу полей, содержащую пк таблицы не обеспечивает никакого дополнительного ограничения. пк сам ля, без ансам, ля уникальный, т.ч. идите лесом со своими пертензиями к уважению. и будет нулл в нейме, или не будет нулл в нейме - пк таблицы то уникальный. или вы умеете создавать не уникальные пк? если да - поделитесь сакральным. мы, невнимательные, поучимся у вас невозможному. Логично. Рассмотрел повнимательнее первое сообщение, оказывается, там объяснение самое полное, тока нерусское. По существу заданных вопросов могу сказать, что накладывать правила на денормализованную структуру - полный кретинизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 06:17 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2006125]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
133ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
| others: | 262ms |
| total: | 482ms |

| 0 / 0 |
