1. PHP / Говнокод #1887

    +158.8

    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
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    $fStr = fgets($fp);
if ($k==0 && $IsFirst)
continue;
$arLine = explode(";", $fStr);
$type = intval($arLine[0]);
$articul = trim($arLine[1]);
$section_id = intval($arLine[2]);
$model = trim($arLine[3]);
$name = trim($arLine[4]);
$brand = trim($arLine[5]);
$width = trim($arLine[6]);
$radius = trim($arLine[7]);
$pcd = trim($arLine[8]);
$et = trim($arLine[9]);
$dia = trim($arLine[10]);
$dop = trim($arLine[11]);
$color = trim($arLine[12]);

//и чуть позже

$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 38, 'S', '".$articul."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 25, 'L', '', ".$type.", '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 17, 'S', '".$width."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 18, 'S', '".$radius."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 19, 'S', '".$pcd."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 20, 'S', '".$et."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 45, 'S', '".$dia."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 21, 'S', '".$color."', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 22, 'S', '0', null, '')";
$res = SQLResult($query);
$query = "INSERT INTO ".$dbCatalogElProp." VALUES (null, ".$element_id.", 23, 'S', '', null, '')";
$res = SQLResult($query);

    Запостил: gorky, 23 Сентября 2009

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

    • ava guest 23.09.2009 15:24 # 0

      а про циклы мы не знаем...
      Ответить

      • ava gorky 23.09.2009 16:41 # 0

        да не только циклы, вообще непонятно зачем разбивать по переменным $arLine.
        про ассоциативные массивы тоже не слыхали.
        Ответить

        • ava interested 23.09.2009 17:04 # −1

          Вообще оно только выглядит страшно, а на самом деле... Попробуйте придумать удобнее.
          Я тоже так делал, когда нужно было парсить большой XML. Десять узлов получаем, кодировку меняем, проверки проводим, вставляем запись в базу. Общаться с десятью разными переменными банально короче по количеству символов. $_varName короче, чем $_varArray['name']. У меня на каждой итерации чтения данных из файла все переменные затирались новыми данными и значениями атрибутов.

          А вот когда ничего не надо было делать, только intval, из CSV файла доставал данные числовые, тогда в sql бросал в поля числа напрямую. Разделял по ; и забрасывал. Никаких проблем. Но идея та же.
          Ответить

          • ava guest 25.09.2009 09:50 # 0

            фтопку.

            а класс который бы это всё далал, как делают великие бледнолицие не пробовал?

            один для работы с бд. с методом для встаки, и передавал бы сюда SQLResult($query); ещё и номер соединения,
            ворой бы парсил XML
            3-й с фильтрами.
            а потом это всё собрать как надо.???
            Ответить

    • ava guest 23.09.2009 18:01 # 0

      1) Какая-то жутковая непонятная структура базы данных.
      2) $res = SQLResult($query); $res = SQLResult($query); -- копипаста такая копипаста...
      3) Раз уж кавычки двойные, то можно было бы и без конкатенации строк обойтись.
      Ну и да, очень подозрительная структура базы данных.
      Ответить

      • ava interested 23.09.2009 18:34 # 0

        Это похоже на какую-то таблицу, определяющую отношение "многие ко многим". Там, где $element_id -- видимо идентификатор сущности, там, где цифры различные -- видимо идентификатор свойства. А переменные, которые вставляются -- значения свойств. Тут нужно глубже смотреть почему была придумана эта таблица...
        Ответить

        • ava gorky 23.09.2009 18:43 # 0

          да, там структура БД довольно сложная. interested прав.
          Ответить

          • ava guest 23.09.2009 20:43 # 0

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

            • ava gorky 24.09.2009 09:16 # 0

              ну к сожалению таких говнорешений там много, стараюсь с ними по возможности бороться по мере появления, хотя меня за это и не поощряют, но оставлять такое просто так не могу. =)
              Ответить

              • ava interested 24.09.2009 09:50 # 0

                Вообще такие таблицы возникают, когда оказывается, что сущности разнородных свойств, но их нужно сопряч. Появляются отношения "многие ко многим", которые только такими таблицами и решаются в случае реляционных БД.

                Если есть таблицы перечесляющая всю оргтехнику в офисе, то таблца сущности будет содержать только бухданные, а все свойства отлетят в отдельную таблицу, которая сопряжётся с оргтехникой через третью. Это произойдёт потому что карандаши обладают совершенно иным набором свойств, чем настольная лампа или принтер.

                Вообще, если я, например, делаю проект, где есть работа с БД, то первым делом я определяю конечные модули, которые общаются с ограниченным числом таблиц. Пересечения сопрягаю через третьи таблицы. Таким образом один кусок программы становится независимым от данных в другом куске.
                Ответить

                • ava interested 24.09.2009 09:56 # +1

                  Ох... приношу извинения за достаточное количество ошибок в русском языке. Но здесь правки сообщений нет =[
                  Ответить

                • ava interested 24.09.2009 09:59 # 0

                  >я определяю конечные модули, которые общаются с ограниченным числом таблиц

                  Ещё более полезной эта практика является при работе с файлами.

                  А с БД это позволяет легче организовать её "нормализованность". Хотя всё равно жизнь расставляет всё своим порядком, дублирование данных всё равно возникает в угоду скорости и минимизации выборок.
                  Ответить

                  • ava gorky 24.09.2009 10:17 # 0

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

                    • ava interested 24.09.2009 11:47 # 0

                      Ой...
                      Ну простите. =]
                      Я видимо не так понял разговор. Если в плане большой копипасты и идентичности строк, то понятное дело, можно было организовать функцию рядом, которая это делает.

                      Относительно циклов -- это вопрос жёсткости контрактов. Если контракт жёсткий, всегда понятно что и сколько входит, то естественно от цикла отказаться. То есть, это в моём мире С++ следует отказаться от цикла, а функции объявить inline. Как в php поступать... Ну я бы по привычке отказался от циклов.
                      Ответить

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