powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / сложный PRIMARY KEY
39 сообщений из 39, показаны все 2 страниц
сложный PRIMARY KEY
    #32095387
whois
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Oracle 8.1.5, есть табличка
  CREATE TABLE b (
    b_num NUMBER(6), -- номер объекта
    created DATE DEFAULT SYSDATE, -- дата создания записи об объекте
    info VARCHAR2(100) -- какая-то информация об объекте
  )
Номера b_num уникальны в пределах года, информация о годе, в принципе, есть в поле created . PRIMARY KEY должен быть вроде ( b_num , ГОД). Но
ALTER TABLE b ADD CONSTRAINT pk_b PRIMARY KEY ( b , TRUNC( created ,'YYYY'))
конечно не проходит. Как тут быть - вводить еще одно поле - ГОД ?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095393
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а почему не устраивает просто PRIMARY KEY (b, created) ? Ну будет ключ на несколько байт больше, ну и что?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095428
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Толковые разработчики делают так: в каждой таблице добавляется дополнительный столбец, который используется именно как первичный ключ и никакой другой информативности не несёт и логически с другими столбцами никак не связан. Значение столбца берётся из сиквенса при каждой вставке новой строки.

Вот и всё.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095438
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Усова на тебя нет;)
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095441
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 софтбилдер

Это не такой уж однозначный вопрос.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095471
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте раскроем тему подробно :)
По мне так искусственный PK нужен тогда, когда он будет использоваться в другой таблице для организации ссылочной целостности, дабы не городить огород.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095475
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...что, строго говоря, не исключает наличия unique-ограничения по полям, представляющим собой настоящий PK.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095510
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, query rewrite с какой версии появился?
У меня на 8.1.7EE, например, вполне проходит вариант
Код: plaintext
1.
2.
3.
SQL> create unique index pk_b on b (b_num, trunc(created,'YYYY'));

Index created.

При условии наличия привилегии query rewrite у юзера.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095710
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"представляющим собой настоящий PK."

Что значит настоящий PK????? Давайте вспомним что такое PK и для чего он
нужен вообще.

Код: plaintext
1.
2.
Первичный ключ(primary key) - это атрибут или группа атрибутов, 
однозначно идентифицирующая экземпляр сущности.

Всё - это единственное правильное определение PK.
Использование же термина "настоящий PK" или "не настоящий PK"
применительно к специальному атрибуту(столбцу) или к атрибутам самой
сущности является некорректным, иначе говоря просто отсебятина.

Требование а PK
Код: plaintext
1.
2.
3.
Значение атрибутов первичного ключа не должно меняться в течении всего
времени существования экземпляра сущности.
Каждая сущность должна иметь хотя-бы один потенциальный ключ.


Исходя из вышеуказанного становится понятно, что использование именно
специального столбца является самым правильным для использованием в
качестве PK. Он гарантировано никогда не будет изменяться, потому-что он не
связан логически с сущностью. Сущность же вообще может не иметь
собственных атрибутов, которые могли бы обеспечивать PK, поэтому именно
введение специального столбца решает эту проблему.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095744
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот не надо грязи и теоретических изысканий :) А то уж очень всесоюзной помойкой под названием su.dbms попахивать начинает.

В данном конкретном случае ключом является номер объекта+год. Он есть. Точка. Если ни в одной другой таблице на эти сущности ссылаться не надо - зачем приделывать к таблице ещё что-то? Если технически реализовать такой сложный ключ можно - зачем вводить дополнительное поле?

killed прав - вопрос неоднозначный, но не с теоретической, а с практической точки зрения...
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095760
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Вот не надо .......теоретических изысканий "

Ну почему же надо? Похоже ты их тех умельцев "самостийных токарей", которые знают как всё делать.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095765
Igor Sablin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
По-моему именно "самостийные токари" знают какое решение САМОЕ правильное :-)
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095802
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Потому что теория, конечно, великая вещь, однако гордость за соответствие заветам не всегда оправдывает медлительность работы и/или глюки. Банально - если у сущности есть некий набор атрибутов, уникально её идентифицирующий среди других сущностей, этот набор является PK. Если бы всё было чиса по Дейтам и пр., так бы все и делали. И внешние ключи были бы композитными. И нахрен не нужны всякие навязанные id. Но так работать неудобно и ресурсоёмко в большинстве случаев. Дешевле ввести id и работать с ним, а естественный PK ограничить unique-констрейнтом, так, как я показал выше. Нужны цифры? Будут, но позже.

Есть ещё интересный момент из области практической реализации - в какой-то подверсии 8.1.6 был баг с таблицами, у которых не задан PK. За давностью лет не помню суть проблемы, подниму переписку если - запостю сюда.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095821
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В конце концов, есть статейка весьма уважаемого мистера Адамса на эту тему - http://www.ixora.com.au/tips/design/synthetic_keys.htm - там и "как" и "почему". Если подумать над "почему", вполне легко решить, нужен ли здесь синтетический ключ, или не нужен.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095832
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095838
ksukhonosenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Товарищи, не надо забывать о ПОТЕНЦИАЛЬНЫХ КЛЮЧАХ - их может быть много - потом из них выбирается один - он и становиться ПЕРВИЧНЫМ.

Так что вот.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095880
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, та трабла, о которой я говорил, оказывается, есть и в 8.1.7.0.0

Итак:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
create or replace procedure calc_rating as
begin
    update
        ratings
    set
        ksi_j = dbms_random.value(- 1 , 1 )
    where
        ( 1  =  1 )
        and id in 
        (
            select
                r.id
            from
                ratings r
            where
                ( 1  =  1 )
                and exists
                (
                    select
                         1 
                    from
                        ratings r1
                    where
                        ( 1  =  1 )
                        and (r1.id = r.id)
                        and (trunc(dbms_random.value( 1 ,  7 )) =  1 )
                )
        );
end;
/
declare i number;
begin
for i in  1 .. 70000  loop
   insert into ratings (id, ksi_j)values (i, 0 );
end loop;
end;
/
begin calc_rating; end;
/
select count(*) from ratings union all select count(*) from ratings where ksi_j !=  0 ;


Ни обновляет ни одной строки, хотя должна ~1/7. После добавления PK на ratings по id всё начинает зашибательски работать. Может кто-нибудь объяснить?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095881
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Забыл про таблицу :)

Код: plaintext
1.
create table ratings (id number( 10 ) not null, ksi_j number( 10 ,  9 ) not null);
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095907
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А где COMMIT?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095926
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И вообще кто вас научил где не поподя вставлять (1=1)? Что вы какой-то хе.....ней занимаетесь? (1=1) всегда возвращает TRUE, это означает, что в целом в условии (операнд AND операнд )всё зависит только от другого условия. Научись сначала запросы писать, потом в дисскусию вступать.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
( 1  =  1 )
        and id in 
        (
            select
                r.id
            from
                ratings r
            where
                ( 1  =  1 )
                and exists
                (
                    select
                         1 
                    from
                        ratings r1
                    where
                        ( 1  =  1 )
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095936
ksukhonosenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
да ладно, нормально написано. Особенно нормально, когда SQL динамически строиться. Тогда "приклеивать" условия удобно.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095941
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Смотри сюда, уважаемый бильдер:

1. commit забыл написать сюда, однако он не есть причина проблемы

2. (1 = 1) к вопросу отношения не имеет - "так сложилось исторически" :) Запросы я писать умею, возможно, не так утончённо, но тем не менее это никак не влияет на то, как оно работает (точнее, не работает).

Если нечего сказать по делу - лучше молчи. Обосрать кого угодно я тоже могу, только желания не испытываю.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095949
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
....Обосрать кого угодно я тоже могу, только желания не испытываю....


Несомневаюсь. Я это уже давно понял.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095980
ksukhonosenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Смотрите, не подеритесь, ... парни" :)
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095982
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для особо, так сказать, процедуру написал покороче:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create or replace procedure calc_rating as
begin
    update ratings
    set ksi_j = dbms_random.value(- 1 ,  1 )
    where id in 
        (
        select r.id from ratings r
        where exists 
            (
            select  1  from ratings r1 
            where (r1.id = r.id) and (trunc(dbms_random.value( 1 ,  7 )) =  1 )
            )
        );
end;
/


Естественно, никаких изменений в функционировании. Кстати, если повторно запустить процедуру на таблице без ключа, обновятся все её строки, что, опять же, неверно.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32095995
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всё равно у тебя запрос неправильный. Дай наполнение таблицы инсертами, что-бы не мучатся. Я у себя посмотрю
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096009
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чем он неправильный? Религией? :)
Наполнение таблицы инсертами - самый тупой вариант:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
declare i number;
begin
for i in  1 .. 70000  loop
   insert into ratings (id, ksi_j) values (i,  0 );
end loop;
end;
/


Тогда, когда я с этим приколом впервые столкнулся (начало 2001 г.), в таблице было как раз примерно 70000 записей. Задача - обновить значение поля ksi_j до некоего рандомического числа в диапазоне (-1, 1) для примерно 1/7 части записей за каждый запуск процедуры. На самом деле, таблица была сложнее, но у меня, к сожалению, не осталось с того времени ничего, восстановил по моментам переписки. Но это не суть, ибо глючит и в приведённом выше варианте.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096048
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Попытаюсь обьяснить в чём твоя ошибка:
вот это выражение trunc(dbms_random.value(1, 7)) = 1 вычисляется всего один раз еще при грамматическом разборе, до выполнения запроса.
Определение случайного числа не происходит для каждой строки запроса. Поэтому если в момент разбора значение функции совпадёт со значением 1 - тогда запрос должен вернуть все строки, если не совпадёт то ни одной.

Попробуй просто повыполняй несколько раз этот запроса и сам убедишься
Код: plaintext
1.
select* from dba_users  where trunc(dbms_random.value( 1 ,  7 ))= 1 


У тебя будет или 0 записей или все - других вариантов не будет.
Если же рассуждать что вызов dbms_random.value происходит для каждой строки, то какой-то строки совпадёт, какой-то нет, в этом случае кол-вот строк может быть каким угодно от 0 до кол-ва строк в таблице.
Реально же получается только 0 или count(*).

Вот так вот. Так что никакого бага или глюка здесь нет.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096124
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вызов dbms_random.value в моей конструкции будет происходить для каждой строки таблицы, т.е. 70000 раз.
Это легко подтверждается как прогоном процедуры на таблице с ключом, так и таким тестом (таблица - с ключом):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
   1    select count(r.id) from ratings r where exists
   2    (
   3     select  1  from ratings r1 where (r1.id = r.id) and (trunc(dbms_random.value( 1 ,  7 )) =  1 )
   4 *  )
SQL> /

COUNT(R.ID)
 -----------
 
       11638 

SQL> /

COUNT(R.ID)
 -----------
 
       11645 

SQL> /

COUNT(R.ID)
 -----------
 
       11693 

SQL> /

COUNT(R.ID)
 -----------
 
       11563 


Здесь видно, что верно предположение о том, что из 70000 последовательно взятых случайных чисел
примерно 1/7 часть будет находится в диапазоне [1, 2). А вот если грохнуть ключ, то, действительно, очень похоже на то,
что dbms_random.value вызывается реально только один раз. Если же ключ не удалять, а задисаблить, запрос подвисает :(
Спрашивается - чем обусловлено такое поведение?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096132
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
План запроса надо смотреть. Когда подключается индекс - меняется план запроса
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096141
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
SQL> set autot trace exp
SQL> /


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      FILTER
    3      2        TABLE ACCESS (FULL) OF 'RATINGS'
    4      2        FILTER
    5      4          INDEX (UNIQUE SCAN) OF 'SSS' (UNIQUE)

SQL> alter table ratings drop constraint sss;

Table altered.

SQL> select...

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      FILTER
    3      2        TABLE ACCESS (FULL) OF 'RATINGS'
    4      2        FILTER
    5      4          TABLE ACCESS (FULL) OF 'RATINGS'


Пока не ясно, почему изменение плана выполнения влияет на результаты запроса.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096159
Фотография softy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А команда создания ключа какая?
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096179
whois
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спасибо за ответы, к сожалению не мог отвечать раньше

.dba
а почему не устраивает просто PRIMARY KEY (b, created) ? Ну будет ключ на несколько байт больше, ну и что?
"b_num уникальны в пределах года", а твой PRIMARY KEY (b_num, created) это обеспечивает??? уникальны в пределах года - значит, что нельзя вставить два одинаковых номера b_ num для дат created одного года
Код: plaintext
1.
INSERT INTO b (b_num, created) VALUES ( 123 , '15.01.03');
INSERT INTO b (b_num, created) VALUES ( 123 , '16.01.03');

ну а так - понятно - можно
Код: plaintext
1.
INSERT INTO b (b_num, created) VALUES ( 123 , '15.01.02');
INSERT INTO b (b_num, created) VALUES ( 123 , '15.01.03');


softbuilder@inbox.ru
Толковые разработчики делают так: в каждой таблице добавляется дополнительный столбец, который используется именно как первичный ключ и никакой другой информативности не несёт и логически с другими столбцами никак не связан. Значение столбца берётся из сиквенса при каждой вставке новой строки.
Вот и всё.
да не совсем всё. я конешно знаю про id, который берется из sequence в триггере BEFORE INSERT, такие ключи у меня есть в 80% таблиц. но вообще-то этот ключ мне нужен был для реализации правила "номер объекта уникален в пределах года" и организации ссылочной целостности в уже существующей таблице, изменять структуру которой нежелательно

Scott Tiger
Кстати, query rewrite с какой версии появился?
У меня на 8.1.7EE, например, вполне проходит вариант
Код: plaintext
1.
2.
SQL> create unique index pk_b on b (b_num, trunc(created,'YYYY'));

Index created.


а что такое query rewrite?
у меня такое не проходит:
Код: plaintext
1.
2.
3.
create unique index pk_b on b (b_num, trunc(created,'YYYY'))
                                                              *
ошибка в строке  1 :
ORA- 02070 : база данных  не поддерживает this date function в этом контексте

на что документация говорит
Код: plaintext
1.
2.
3.
4.
ORA- 02070  database stringstring does not support string in this context

Cause: The remote database does not support the named capability in the context in which it is used.

Action: Simplify the SQL statement. 
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096191
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2softbuilder:

самая простая

Код: plaintext
1.
alter table ratings add constraint sss primary key(id);
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096198
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2whois:
По поводу query rewrite см. Oracle8i Data Warehousing Guide, для 8.1.6 это глава 19. Даёт, в том числе, возможность использования функциональных индексов. Надо в pfile поставить query_rewrite_enable = true и дать grant query rewrite to <user>
Кстати, для вставки инкрементирующихся значений триггерами лучше не пользоваться, лучше честно вызывать sequence_name.nextval.
А вот если query rewrite у тебя не работает, то разве что триггером можно будет реализовать такое ограничение целостности при вставке и обновлении, не изменяя структуры таблицы. Если у тебя много insert-ов, лучше будет изменить структуру, если мало - приделать триггер, в любом случае проапгрейдить 8.1.5 - версия кривая.
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096335
whois
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Scott Tiger:
спасибо за прояснение ситуации. конечно, query rewrite - наш выбор ))), но и на 8.1.5 можно исхитриться - 8.1.5 также позволяет создавать функциональные индексы (Function-based Index):
Код: plaintext
1.
2.
3.
CREATE UNIQUE INDEX idx_b ON b (b_num, TRUNC(created,'YYYY'));
                                                     *
ошибка в строке  1 :
ORA- 02070 : база данных  не поддерживает this date function в этом контексте

создаем функцию с директивой DETERMINISTIC:
Код: plaintext
1.
2.
3.
4.
CREATE OR REPLACE FUNCTION year (adate DATE) RETURN DATE DETERMINISTIC IS
BEGIN
  RETURN trunc(adate,'YYYY');
END year;
/

и далее:
Код: plaintext
1.
2.
CREATE UNIQUE INDEX idx_b ON b (b_num, year(created)); 

Индекс создан.

ну это уже хоть что-то )), хотя PRIMARY KEY (b_num, year(created)) и UNIQUE (b_num, year(created)) продолжают ругаться:
Код: plaintext
1.
2.
3.
ALTER TABLE b ADD CONSTRAINT pk_b PRIMARY KEY (band_num, year(created))
                                                              *
ошибка в строке  1 :
ORA- 00907 : отсутствует правая скобка

теперь
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
INSERT INTO b(b_num, created) VALUES( 123 , sysdate);

 1  строка создана.
INSERT INTO b(b_num, created) VALUES( 123 ,  sysdate+ 1 );
INSERT INTO b(b_num, created) VALUES( 123 ,  sysdate+ 1 )
            *
ошибка в строке  1 :
ORA- 00001 : нарушено ограничение уникальности (IDX_B)


по поводу апгрейда 8.1.5 PE до 8.1.6, 8.1.7 - так понимаю, что "поверх" поставить нельзя, нужно искать дистрибутив? и прокатит ли просто подложить ему старые файлы бд и создать новую службу:
oradim -new -sid MYSID -intpwd ******** -startmode manual -pfile X:\Oracle\admin\MyDB\pfile\init.ora?

Кстати, для вставки инкрементирующихся значений триггерами лучше не пользоваться, лучше честно вызывать sequence_name.nextval.
мммм. что именно ты имеешь ввиду? вызывать откуда? я делаю так:
Код: plaintext
1.
2.
3.
4.
5.
6.
CREATE OR REPLACE TRIGGER trg_b_ins BEFORE INSERT
ON b FOR EACH ROW  --WHEN (new.b_id=0 OR new.b_id IS NULL)
 
BEGIN
  SELECT seq_b_id.nextval INTO :new.b_id FROM dual;
END trg_b_ins;
/
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32096355
vskv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
по поводу апгрейда  8 . 1 . 5  PE до  8 . 1 . 6 ,  8 . 1 . 7  - так понимаю, 
что  "поверх"  поставить нельзя, нужно искать дистрибутив?
и прокатит ли просто подложить ему старые файлы бд 
и создать новую службу: 
oradim -new -sid MYSID -intpwd ******** -startmode manual -pfile X:\Oracle\admin\MyDB\pfile\init.ora? 


К сожалению, с 8.1.5 такой фокус (со старыми файлами) не пройдёт -- нужно мигрировать. Но дистрибутив 8.1.5 тебе для этого не нужен.
Вот файлы от 8.1.6 уже можно в лоб апгрейдить до 8.1.7.х

Код: plaintext
1.
2.
3.
    Кстати, для вставки инкрементирующихся значений триггерами 
    лучше не пользоваться, лучше честно вызывать sequence_name.nextval. 
мммм. что именно ты имеешь ввиду? вызывать откуда? я делаю так: ...

Вот именно так и не советовали делать. Имелось ввиду, что правильнее выбирать seq.nextval в самом операторе вставки:
Код: plaintext
insert into TabName values (seq.nextval, dc1, dc2);

А в триггере оставить только защитную логику (на NULL значение PK).
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32098565
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А почему нельзя просто

CREATE OR REPLACE TRIGGER trg_b_ins BEFORE INSERT
ON b FOR EACH ROW
BEGIN
new.created = TRUNC(sysdate,'YYYY');
END trg_b_ins;
...
Рейтинг: 0 / 0
сложный PRIMARY KEY
    #32099016
whois
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to SERG1257

в данном случае created обязательно должно хранить фактическую дату записи, а не только год. триггерами-то конешно можно, только тебе надо еще проверять отсутствие номера в пределах года. смысл был в использовании встроенных механизмов обеспечения целостности. ты же не реализуешь, например, обычный первичный ключ как-то вручную, триггерами или еще как?
...
Рейтинг: 0 / 0
39 сообщений из 39, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / сложный PRIMARY KEY
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]