1. SQL / Говнокод #8630

    −110

    1. 1
    2. 2
    3. 3
    CREATE INDEX "SCHEMANAME"."PLIN_DPINS_FK_I" ON "SCHEMANAME"."CLIENT_PLAN_INSTALMENTS" ("DPLNS_PLAN_ID", "DPOPT_OPTION_ID", "INSTALMENT_NUM");
    CREATE UNIQUE INDEX "SCHEMANAME"."PLIN_PK" ON "SCHEMANAME"."CLIENT_PLAN_INSTALMENTS" ("CLI_CLIENT_ID", "DPLNS_PLAN_ID", "DPOPT_OPTION_ID", "CLIPLN_PLAN_DATE", "CLIPLN_PLAN_TYPE", "INSTALMENT_NUM");
    CREATE UNIQUE INDEX "SCHEMANAME"."CLIPLN_PK" ON "SCHEMANAME"."CLIENT_PLAN" ("CLI_CLIENT_ID", "DPLNS_PLAN_ID", "DPOPT_OPTION_ID", "PLAN_DATE", "PLAN_TYPE");

    Реляционные? Не, не слышал.

    Запостил: govnoguest, 24 Ноября 2011

    Комментарии (8) RSS

    • А что-то я и не понял в чем прикол, при чем тут реляционность, данных для оценки реляционности явно недостаточно.
      Ответить
      • так govnoguest же :)
        Ответить
      • странные индексы уникальности...
        Ответить
      • Это объявление первичного и внешнего "ключей" на реальных таблицах. Oracle. Про ADD PRIMARY KEY/ADD FOREIGN KEY товарищи либо не в курсе, либо, что вероятнее, БД им не позволила создать "первичный ключ" шириной в 6 полей.
        Ответить
        • А если мне НЕ нужен Foreign Key Constraint? Ну с примари ключем затуп, это понятно, но вполне допустимо, особенно в высоконагруженных проектах, не декларировать foreign key constraint. Имхо, код можно назвать говнокодом с боооольшой натяжкой.
          Ответить
          • Проблема не в отсутствии констрейнтов. Проблема в отсутствии понимания, как работают реляционные БД. В результате имеем в схеме "ключи" по 5-7 полей, и огромное количество таких вот запросов:
            SELECT /*+ FIRST_ROWS */ instalment_amount
                     INTO    :payment_option.pmt_amount
                     FROM    client_plan_instalments cpi,
                 	         client_plan cp       		   
                     WHERE   cp.cli_client_id               = v_client_id
            		 AND   cp.notice_id            = TO_NUMBER(:global.as220_act_notice_id)
                             AND   cp.dpopt_option_id      = 2
            		 AND   cpi.cli_client_id       = cp.cli_client_id
            		 AND   cpi.dplns_plan_id       = cp.dplns_plan_id
            		 AND   cpi.dpopt_option_id     = cp.dpopt_option_id
            		 AND   cpi.clipln_plan_date    = cp.plan_date
            		 AND   cpi.clipln_plan_type    = cp.plan_type
                             AND   cpi.dpins_instalment_id = 1
                             AND   cp.revenue_type         = 'L';


            Честно говоря, я думал это было очевидно изначально.
            Ответить
            • а что, если они ДОЛЖНЫ быть юниками? А то, что индекс может иногда потребоваться составить с 5-7 полями, - так это как пить дать.
              Да и при чем тут SELECT-запрос-то? При селекте мне без разницы какая связка объявлена как UNIQUE, ровно как и то, как составлен индекс. При объявления UNIQUE меня волнует то, что у меня связка уникальная в таблице всегда, при добавлении индекса по нескольким полям я хочу добиться максимально быстрых SELECT'ов, если основная часть запросов использует одновременно все поля, которые были использованы при составлении индекса, - вот и всё. Я ваш пример до сих пор не понял.
              Ответить
              • простыню не читал
                тут либо составной ключ just as planned
                либо поциэнт cannot into синтетические ключи
                Ответить

    Добавить комментарий