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

    −172

    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
    CREATE TABLE `cache_lead_emails` (
    	`id` INT(10) NOT NULL AUTO_INCREMENT,
    	`created_on_date` DATETIME NULL DEFAULT NULL,
    	`some_id_1` BIGINT(20) NULL DEFAULT NULL,
    	`some_id_2` BIGINT(20) NULL DEFAULT NULL,
    	`some_id_3` BIGINT(20) NULL DEFAULT NULL,
    	`some_id_4` BIGINT(20) NULL DEFAULT NULL,
    	`index_letter` VARCHAR(1) NULL DEFAULT NULL,
    	`writable` ENUM('Yes','No') NULL DEFAULT NULL,
    	`emails` TEXT NULL,
    	PRIMARY KEY (`id`)
    )
    COLLATE='utf8_general_ci'
    ENGINE=InnoDB
    
    "4"	"2013-03-12 17:56:38"	"1"	"3"	"3"	"3"	"G"	"Yes"	"4:g****@gmail.com,26:g****@hotmail.com,29:g*****@hotmail.com,116:g****@gmail.com"
    "5"	"2013-03-12 17:56:38"	"1"	"3"	"3"	"3"	"I"	"Yes"	"5:i******@gmail.com,44:i*****@gmail.com"

    Sorry for the English.
    This is a cache table holding emails separated by letter. For example I`ve shown all e-mails starting with G ( its only one row for all of them). I still don`t know where the digits separating the e-mails come from.
    The field "writable" is set to "No" immediately before update and hen updated to "Yes" after update so .. it basically is creative LOCK mechanism :)
    brilliant!

    Google translate:
    Извините за английский язык.
    Это кэш-стол с электронной почты, разделенных буквой. Например, я `ве показаны все сообщения электронной почты, начинающиеся с G (ее только одна строка для каждого из них). Я до сих пор не знаю, где цифры отделения электронной почты родом.
    В поле "записи" установлен в положение "No" непосредственно перед обновления и курица обновленный "Yes" после обновления так .. это в принципе творческого механизма LOCK :)
    блестящий

    Запостил: gotha, 13 Марта 2013

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

    • > кэш-стол
      > я `ве
      > и курица обновленный "Yes"
      > творческого механизма

      Please, DO NOT use google translate!
      Ответить
      • I have no idea how bad google translate is, I suppose Yandex may be better, but still ...
        Despite the fact I am slav, I don`t know Russian at all, I understand some words, but I can`t build a sentance so I thought that GT can be at least a little bit of help.

        I cannot edit it,so please, admins, if you think it is necessary, delete my post.
        Regards.
        Ответить
    • Use http://translate.yandex.ru
      Ответить
      • хуле, надо продвигать отечественного производителя
        Ответить
        • Справедливости ради надо признать, что у Яндекса перевод получился лучше. Особенно если курицу на "then" исправить )
          Ответить
    • Greetings.

      I will not buy this record, it is scratched. My hovercraft is full of eels. Do you want... do you want... to come back to my place, bouncy bouncy? If I said you had a beautiful body, would you hold it against me... I am no longer infected.

      Hope it will help, with best regards.
      Ответить
    • > I still don`t know where the digits separating the e-mails come from.
      Check respective cache_lead_emails.id's

      > The field "writable" is set to "No" immediately before update and hen updated to "Yes" after update so .. it basically is creative LOCK mechanism :)
      Probably, some "INSTEAD OF UPDATE" trigger exists on a table which is checking "writable" column state? In this case it doesn't look useless...
      Ответить
      • It turns out, that the IDs in between e-mails are IDs from another table.
        No, no such trigger.
        Ответить
    • Bollywood rulez!
      Ответить
    • РУССКИЙ, УБЛЮДОК. ТЫ РАЗГОВАРИВАЕШЬ НА НЕМ?
      Ответить
    • - Да, ты уловил мой стиль. Можно было и что-нибудь подешевле взять, но в том же ключе.
      Ответить

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