mysql_real_escape_string / Говнокод #23214 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  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 Kaldblpb, (Updated )

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

  • ava inkanus-gray # Ссылка на оригинал 0

    Наименования не очень удачные, а так без контекста трудно понять, что здесь к чему.
    Ответить

  • ava Kaldblpb # Ссылка на оригинал 0

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

  • ava Dummy00001 # Ссылка на оригинал 0

    > TBL_JOUR_PRODUCTION_PLAN_KK_BH_HISTORY

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

    часто (в финансах, например; но не только) нужно держать не только текущие данные, но так же и данные на момент совершения транзакции (versions & history).
    Ответить

  • ava Kaldblpb # Ссылка на оригинал 0

    Контекст совершенно не при чем, естественно присутствую таблицы истории, если таковая ведется. Дело в подходе, в префиксах, их цель - унификация названия поля в рамках всей БД. На практике - не читаемые запросы и очень тяжелое обслуживание, на мой взгляд, подход совершенно не оправдан. Самая жопа если база крупная и таблиц много, префиксы начинают совпадать, становятся нелогичными. До коллег эту мысль, к сожалению, донести не смог,
    аргумент был железный - "если надо поле переименовать, проще найти где оно встречается" ) не поспоришь, а то что с этим потом работать и возможно уже не нам, насрать... Реально, в такой базе разберется только тот, кто эти таблицы создавал. Все выше написанное - моё ИМХО, основанное на многолетнем опыте.
    Если есть сторонники префиксов, с удовольствием поспорю)
    Ответить

    • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

      Пусть тогда и члены классов с полным префиксом называют (включаю ванга-мод и предполагаю, исходя из выбранной DBMS, что проект на C#)
      // Хочется переименовать сущность? sed!
// Autocomplete? Просто используйте grep.
namespace AwesomeProject {
  class AwesomeProject_AwesomeClass {
    public AwesomeProject_AwesomeClass_Field { get; set; }
  }
}
      Ответить

      • ava bormand # Ссылка на оригинал 0 ⇈

        > Пусть тогда и члены классов с полным префиксом называют
        Уже было в джаве:
        InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
        Ответить

        • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

          Ну да, тут хотя бы видно, где отдельные слова начинаются. Немного лучше, чем Meinungsverschiedenheit, Unabhaengigkeitserklaerungen und Donaudampfschiffahrtsgesellschaftskapitän
          Ответить

    • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

      я считаю такой подход глупостью, обоснование у меня простое. Предположим, что разработка в принципе причиняет (попо)боль, но мы хотим эту боль минимизировать. Боль причиняется трёмя способами: при чтении кода, при его изменении и при переименовании сущностей. Назначим этим событиям вероятность и посмотрим на матожидание.

      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 раз больше, чем от их отсутствия.
      Ответить

  • ava Kaldblpb # Ссылка на оригинал 0

    Постил с целью услышать другие мнения.
    Говнокодом, как таковым, написанное вовсе не считаю)
    Ответить

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

Помни, guest, за тобой могут следить!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓