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

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    CREATE TABLE [dbo].[TBL_JOUR_PRODUCTION_PLAN_KK_BH](
    	[JPPKKBH_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBH_JPKKBH_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBH_WC_ID] [int] NOT NULL,
    	[JPPKKBH_DATE] [datetime] NOT NULL,
    	[JPPKKBH_QTY] [numeric](30, 5) NOT NULL,
    	[JPPKKBH_QTYF] [numeric](30, 5) NOT NULL,
    	[JPPKKBH_COMENT] [varchar](8000) NULL,
    	[JPPKKBH_DESCRIPTION] [varchar](8000) NOT NULL,
    	[JPPKKBH_WHO] [varchar](150) NOT NULL,
    	[JPPKKBH_WHO_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBH_WHEN] [datetime] NOT NULL,
    (
    
    CREATE TABLE [dbo].[TBL_JOUR_PRODUCTION_PLAN_KK_BH_HISTORY](
    	[JPPKKBHH_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBHH_JPPKKBH_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBHH_JPPKKBH_JPKKBH_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBHH_JPPKKBH_WC_ID] [int] NOT NULL,
    	[JPPKKBHH_JPPKKBH_DATE] [datetime] NOT NULL,
    	[JPPKKBHH_JPPKKBH_QTY] [numeric](30, 5) NOT NULL,
    	[JPPKKBHH_JPPKKBH_QTYF] [numeric](30, 5) NOT NULL,
    	[JPPKKBHH_JPPKKBH_COMENT] [varchar](8000) NULL,
    	[JPPKKBHH_JPPKKBH_DESCRIPTION] [varchar](8000) NOT NULL,
    	[JPPKKBHH_JPPKKBH_WHO_ID] [uniqueidentifier] NULL,
    	[JPPKKBHH_JPPKKBH_WHEN] [datetime] NOT NULL,
    	[JPPKKBHH_OPER] [int] NOT NULL,
    	[JPPKKBHH_WHO_ID] [uniqueidentifier] NOT NULL,
    	[JPPKKBHH_WHEN] [datetime] NOT NULL,
    (

    no comments

    Запостил: Kaldblpb, 25 Июля 2017

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

    • Что не так?
      Ответить
    • Наименования не очень удачные, а так без контекста трудно понять, что здесь к чему.
      Ответить
    • Немного забыли, что код пишется не только для машины, и сделали из нелогичной базы нечитаемую)
      Новому программисту будет чрезвычайно сложно в ней работать.
      Ответить
    • > TBL_JOUR_PRODUCTION_PLAN_KK_BH_HISTORY

      с какой то вероятностью - не говно. потому что даже в имени второй таблицы стоит: HISTORY.

      часто (в финансах, например; но не только) нужно держать не только текущие данные, но так же и данные на момент совершения транзакции (versions & history).
      Ответить
    • Контекст совершенно не при чем, естественно присутствую таблицы истории, если таковая ведется. Дело в подходе, в префиксах, их цель - унификация названия поля в рамках всей БД. На практике - не читаемые запросы и очень тяжелое обслуживание, на мой взгляд, подход совершенно не оправдан. Самая жопа если база крупная и таблиц много, префиксы начинают совпадать, становятся нелогичными. До коллег эту мысль, к сожалению, донести не смог,
      аргумент был железный - "если надо поле переименовать, проще найти где оно встречается" ) не поспоришь, а то что с этим потом работать и возможно уже не нам, насрать... Реально, в такой базе разберется только тот, кто эти таблицы создавал. Все выше написанное - моё ИМХО, основанное на многолетнем опыте.
      Если есть сторонники префиксов, с удовольствием поспорю)
      Ответить
      • Пусть тогда и члены классов с полным префиксом называют (включаю ванга-мод и предполагаю, исходя из выбранной DBMS, что проект на C#)
        // Хочется переименовать сущность? sed!
        // Autocomplete? Просто используйте grep.
        namespace AwesomeProject {
          class AwesomeProject_AwesomeClass {
            public AwesomeProject_AwesomeClass_Field { get; set; }
          }
        }
        Ответить
        • не продумали, надо предложить :-D
          Ответить
        • # AwesomeProject_AwesomeClass_Field

          AwesomeProject_AwesomeClass_AwesomeField
          Ответить
        • > Пусть тогда и члены классов с полным префиксом называют
          Уже было в джаве:
          InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
          Ответить
          • Ну да, тут хотя бы видно, где отдельные слова начинаются. Немного лучше, чем Meinungsverschiedenheit, Unabhaengigkeitserklaerungen und Donaudampfschiffahrtsgesellschaftskapitän
            Ответить
      • я считаю такой подход глупостью, обоснование у меня простое. Предположим, что разработка в принципе причиняет (попо)боль, но мы хотим эту боль минимизировать. Боль причиняется трёмя способами: при чтении кода, при его изменении и при переименовании сущностей. Назначим этим событиям вероятность и посмотрим на матожидание.

        M(Butthurt) = Butthurt(Reading) * p(Reading) + Butthurt(Writing) * p(Writing) + Butthurt(Rename) * p(Rename)

        Предположим, теперь, исходя из наблюдений, что код читается в 10 раз чаще, чем пишется, и новый код пишется в 50 раз чаще, чем переименовываются сущности. Сравним матожидание боли с префиксами и без префиксов, положив

        Butthurt(Reading | Prefixes) = over 9000
        Butthurt(Reading | No Prefixes) = 1000

        Butthurt(Writing | Prefixes) = over 9000
        Butthurt(Writing | No Prefixes) = 2000

        Butthurt(Renaming | Prefixes) = 1000
        Butthurt(Renaming | No Prefixes) = 5000

        M(Butthurt | Prefixes) = 9000 * 500 / 551 + 9000 * 50 / 551 + 1000 * 1 / 551 ~= 8985
        M(Butthurt | No Prefixes) = 1000 * 500 / 551 + 2000 * 50 / 551 + 5000 * 1 / 551 ~= 1098

        Итого, суммарное кол-во попоболи от префиксов в рамках нашей модели почти в 9 раз больше, чем от их отсутствия.
        Ответить
    • Постил с целью услышать другие мнения.
      Говнокодом, как таковым, написанное вовсе не считаю)
      Ответить

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