dev.net.ua

Українська Спільнота Розробникiв
 
Ласкаво просимо до dev.net.ua Увійти | Приєднатися | Допомога | Увійти Live ID
в Пошук

Як правильно реалізувати зв'язок "багато-до-багатьох"

Останнє повідомлення 28-02-2008, 3:27 від Mike Chaliy. 4 відповіді.
Сортувати: Попереднє Наступне
  •  24-02-2008, 6:58 5487

    Як правильно реалізувати зв'язок "багато-до-багатьох"

    Посовітуйте, які переваги та недоліки таких реалізацій зв'язку "багато-до-багатьох". Використовується MS SQL 2005.

    Є дві таблиці:

    CREATE TABLE [dbo].[users](


    [userid] [int] IDENTITY(1,1) NOT NULL,


    [username] [varchar](50) NOT NULL,


    CONSTRAINT [PK_users] PRIMARY KEY CLUSTERED


    (


    [userid] ASC


    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]


    ) ON [PRIMARY]

     

    Та

    CREATE TABLE [dbo].[roles](


    [roleid] [int] IDENTITY(1,1) NOT NULL,


    [rolename] [varchar](50) NOT NULL,


    CONSTRAINT [PK_roles] PRIMARY KEY CLUSTERED


    (


    [roleid] ASC


    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]


    ) ON [PRIMARY]

     

    Можливі варіанти створення зв'язку "багато-то-багатьох":

    1)      1)

    CREATE TABLE [dbo].[user_roles](


    [userid] [int] NOT NULL,


    [roleid] [int] NOT NULL,


    CONSTRAINT [PK_user_roles] PRIMARY KEY NONCLUSTERED


    (


    [userid] ASC,


    [roleid] ASC


    ))





    GO


    ALTER TABLE [dbo].[user_roles] WITH CHECK ADD CONSTRAINT [FK_role] FOREIGN KEY([roleid])


    REFERENCES [dbo].[roles] ([roleid])


    GO


    ALTER TABLE [dbo].[user_roles] CHECK CONSTRAINT [FK_role]


    GO


    ALTER TABLE [dbo].[user_roles] WITH CHECK ADD CONSTRAINT [FK_user] FOREIGN KEY([userid])


    REFERENCES [dbo].[users] ([userid])


    GO


    ALTER TABLE [dbo].[user_roles] CHECK CONSTRAINT [FK_user]


    GO

    2)      2)

    CREATE TABLE [dbo].[user_roles2](


    [user_roles_id] [int] IDENTITY(1,1) NOT NULL,


    [userid] [int] NOT NULL,


    [roleid] [int] NOT NULL,


    CONSTRAINT [PK_user_roles2] PRIMARY KEY CLUSTERED


    (


    [user_roles_id] ASC


    ))


    GO





    CREATE UNIQUE NONCLUSTERED INDEX [IX_unique_user_roles] ON [dbo].[user_roles2]


    (


    [userid] ASC,


    [roleid] ASC


    )


    GO





    ALTER TABLE [dbo].[user_roles2] WITH CHECK ADD CONSTRAINT [FK_user_roles2_roles] FOREIGN KEY([roleid])


    REFERENCES [dbo].[roles] ([roleid])


    GO


    ALTER TABLE [dbo].[user_roles2] CHECK CONSTRAINT [FK_user_roles2_roles]


    GO


    ALTER TABLE [dbo].[user_roles2] WITH CHECK ADD CONSTRAINT [FK_user_roles2_user] FOREIGN KEY([userid])


    REFERENCES [dbo].[users] ([userid])


    GO


    ALTER TABLE [dbo].[user_roles2] CHECK CONSTRAINT [FK_user_roles2_user]


    GO

     

    Можливі недоліки другого варіанту - збільшення часу додавання запису через додатковий індекс.

       

    Шановне товариство, скажіть які можуть бути "За" та "Проти" обох варіантів.
  •  25-02-2008, 0:23 5490 у відповідь на 5487

    Re: Як правильно реалізувати зв'язок "багато-до-багатьох"

    Це запитання я задавав також на форумі по базам даних на sql.ru .

    Ось тут підсумки короткого обговорення.
  •  25-02-2008, 23:25 5504 у відповідь на 5487

    Re: Як правильно реалізувати зв'язок "багато-до-багатьох"

    Це своє питання я задав на форумі по MS SQL Database Engine насайті Microsoft. Отримав одну відповідь, скоріше за перший варіант:

    " I would go with #1 generally speaking, but you may want to test the performance change by creating a nonclustered index on your composite primary key and then having a clustered index on the userid column alone.  If I recall from past experience correctly, there was a significant enough difference in performance to warrant this change since most of our queries were searching the table on just the userid column.  I would have to go back and review some release notes on this to be certain, but the clustered index on the composite key didn't do as good of a job satisfying requests on the user id as a single column clustered index on userid, with a nonclustered unique index on the composite key did.  The table was over a ten million rows at the point we saw any difference I believe."

    Дивітсь тут:  http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2900310&SiteID=17
  •  26-02-2008, 13:46 5524 у відповідь на 5504

    Re: Як правильно реалізувати зв'язок "багато-до-багатьох"

    Памятаю, в мене на проекті колись теж була така дилема... вибрали перший варіант і всі були задоволені :) Але як правильно сказали на sql.ru "усе залежить від специфіки задачі"

    If you can't solve the problem, just *** it!
  •  28-02-2008, 3:27 5543 у відповідь на 5487

    Re: Як правильно реалізувати зв'язок "багато-до-багатьох"

    2ViktorZ, дякую(або дякуємо) що виклав результати пошуку тут.
    MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)
Переглядати як новосний Блог RSS в XML