SQL (достъп) - добавяне на ново поле към съставен първичен ключ

Имам таблица, наречена table1, която има съставен първичен ключ, използващ „ScreenId“ и „ActivityItemId“. Добавих ново поле „ProductId“, което има ограничение NOT NULL. Искам да добавя ProductId към съставния първичен ключ.

Мислех, че това ще проработи

db.execute "ALTER TABLE table1 PRIMARY KEY (ScreenId, ActivityItemId, ProductId)"

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

Може ли някой да ми помогне с SQL? (тук между другото не мога да използвам визуално основно решение, всъщност използвам ruby ​​интерфейс, за да стартирам sql, така че трябва да е само в SQL)

благодаря макс


sql database-design ms-access
person Max Williams    schedule 02.08.2009    source източник

Отговори (3)


arrow_upward
6
arrow_downward

Опитайте да премахнете текущия си първичен ключ и след това създайте нов:

ALTER TABLE table1 DROP CONSTRAINT pk_name

ALTER TABLE table1 ADD CONSTRAINT pk_name PRIMARY KEY (ScreenId, ActivityItemId, ProductId)

person Sergey Olontsev    schedule 02.08.2009
comment
Благодаря Hawx - но получавам тази грешка OLE код на грешка:80004005 в Microsoft JET Database Engine CHECK ограничение „Първичен ключ“ не съществува. Пусках това - може би това не е правилният синтаксис? ALTER TABLE table1 DROP CONSTRAINT [PrimaryKey] - person Max Williams; 02.08.2009
comment
Вместо [Първичен ключ] използвайте името на основния ключ. - person Sergey Olontsev; 02.08.2009
comment
а, разбирам, квадратни скоби като в „вмъкнете вашата променлива тук“.\n Страхувам се, че все още нямам късмет - изпълнявам това: ALTER TABLE Activity DROP CONSTRAINT ScreenId и получавам тази грешка обратно CHECK constraint „ScreenId“ не съществуват. ScreenId определено е едно от полетата за първичен ключ в тази таблица. Това е DB за достъп - може би има различен синтаксис, необходим за достъп? благодаря много - макс - person Max Williams; 02.08.2009
comment
Точно това е синтаксисът на Access, взет от онлайн помощта на Access. Проблемът е, че името на ограничението за първичен ключ е грешно. Също така опитайте това ALTER TABLE Activity DROP CONSTRAINT PrimaryKey; Надявам се, че ще изпусне първичния ключ, без да знае името му. - person Sergey Olontsev; 02.08.2009
comment
Успях да премахна първичния ключ - действителното име на съставния ключ беше „Key1“ и това беше, което трябваше да предам на клаузата „DROP CONSTRAINT“. Добавянето на нов бит за първичен ключ работи за първи път. Благодаря ви много за помощта, момчета! макс - person Max Williams; 02.08.2009

arrow_upward
3
arrow_downward

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

Може да си струва да запазите тези връзки като уникални ограничения и да добавите сурогатен ключ.

person duffymo    schedule 02.08.2009
comment
+1: Съставен първичен ключ, който се променя всъщност не е основен. Той се промени, така че не е единственият идентификатор за реда. Направете съставния ключ обикновен индекс и добавете уникален сурогатен ключ. - person S.Lott; 02.08.2009
comment
Благодаря Duffymo. Това всъщност не е моята бизнес логика, ние не бихме използвали достъп за нашия бизнес :) Това наистина е само еднократна работа.‹br/›Като казах, че не съм против използването на сурогатен ключ за решаване на проблема , но не съм чувал термина преди. Ще го потърся. - person Max Williams; 02.08.2009
comment
Много добре, Макс. Ако използвате Access, добавете колона с име id, която е от тип AutoNumber и сте добре. Използвайте уникално ограничение за другите колони. - person duffymo; 02.08.2009
comment
-1 Не искате да променяте схемата си всеки път, когато бизнес логиката ви се промени - може да не искате, но промяната на схемата е неизбежна, когато бизнес логиката се промени. Освен това естественият ключ срещу сурогатното е религиозен въпрос. - person onedaywhen; 03.08.2009
comment
Виждал съм бази данни, които използват номер на социална осигуровка като първичен ключ за потребител, защото беше естествено да трябва да се разбърква, когато законите за поверителност затрудняват получаването му. Нищо религиозно в това. - person duffymo; 04.08.2009
comment
@duffymo: съгласен, изборът на грешен естествен ключ не е религиозен въпрос. Въпреки това, предлагането на сурогатен ключ, без да се знае (по-скоро без да се интересуват) за индивидуалните обстоятелства, е религиозен въпрос. - person onedaywhen; 04.08.2009
comment
Нямаш представа дали ми пука или не. Неправилен си, като го приемеш. - person duffymo; 05.08.2009

arrow_upward
-1
arrow_downward

Опитвали ли сте да промените първичния ключ с изгледа за проектиране, вместо да използвате SQL?

person Walter Mitty    schedule 03.08.2009
comment
-1 те казаха, че всъщност използвам ruby ​​интерфейс, за да стартирам sql, така че трябва да е само в SQL. - person onedaywhen; 03.08.2009
comment
опа! Моя грешка. Все още бих бил любопитен през какви движения ви кара да преминете през интерфейса на дизайнерския изглед, за да изпълните тази задача. Макс получи решението, което търсеше, веднага щом научи как да наименува ограничението, което се опитваше да премахне. Всичко е наред, щом свършва добре. - person Walter Mitty; 04.08.2009
comment
Едно нещо относно използването на интерфейса, за което не съм сигурен, е как да укажа реда на колоните в PK, т.е. ScreenId, след това ActivityItemId и след това ProductId в този ред. Това е много важно, когато имате предвид, че механизмът на базата данни на Access използва PK за физическо групиране на данни на диск. Какво става, ако потребителският интерфейс винаги добавя новата колона след всички останали? Как да разбера дали е така или не? Поради неизвестните за мен е по-безопасно да използвам SQL DDL. - person onedaywhen; 04.08.2009