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

    • ava AxisPod 24.11.2011 06:53 # +5

      А что-то я и не понял в чем прикол, при чем тут реляционность, данных для оценки реляционности явно недостаточно.
      Ответить

      • ava JeremyW 24.11.2011 08:40 # +4

        так govnoguest же :)
        Ответить

      • ava Lure Of Chaos 24.11.2011 12:04 # +9

        странные индексы уникальности...
        Ответить

      • ava govnoguest 25.11.2011 00:35 # +1

        Это объявление первичного и внешнего "ключей" на реальных таблицах. Oracle. Про ADD PRIMARY KEY/ADD FOREIGN KEY товарищи либо не в курсе, либо, что вероятнее, БД им не позволила создать "первичный ключ" шириной в 6 полей.
        Ответить

        • ava Nemoden 25.11.2011 04:20 # 0

          А если мне НЕ нужен Foreign Key Constraint? Ну с примари ключем затуп, это понятно, но вполне допустимо, особенно в высоконагруженных проектах, не декларировать foreign key constraint. Имхо, код можно назвать говнокодом с боооольшой натяжкой.
          Ответить

          • ava govnoguest 25.11.2011 07:02 # 0

            Проблема не в отсутствии констрейнтов. Проблема в отсутствии понимания, как работают реляционные БД. В результате имеем в схеме "ключи" по 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';


            Честно говоря, я думал это было очевидно изначально.
            Ответить

            • ava Nemoden 25.11.2011 08:19 # 0

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

              • ava bugmenot 25.11.2011 12:23 # +1

                простыню не читал
                тут либо составной ключ just as planned
                либо поциэнт cannot into синтетические ключи
                Ответить

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