1. C++ / Говнокод #15794

    +64

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    QSqlQuery my_query;
my_query.prepare(
          QString("INSERT INTO table1 (number, address, age) VALUES (%1, '%2', %3);")
                          .arg(fromInput1).arg(fromInput2).arg(fromInput3)
          );

    Жаль, но похоже автор не осилил экранирование от SQL-иньекций.

    Запостил: LispGovno, 19 Апреля 2014

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

    • ava LispGovno 19.04.2014 22:31 # 0

      Кстаи, полнотекстовой поиск только в SQLite по дефолту отключен, а в нормальных БД он обычно всегда включен по дефолту?
      И кстати полнотекстовой поиск в нормальных БД только по слову целеком ищет или может и по части слова? Слышал что SQLite может только слова индексировать полностью, а не их части.
      Ответить

      • ava bormand 19.04.2014 23:41 # +2

        Для полнотекстового отдельные особые индексы строятся.
        Ответить

        • ava LispGovno 20.04.2014 07:35 # 0

          Я слышал, что для SQLite это обычные деревья поиска слов, отсортированные в лексикографическом порядке. То есть по сути быстро найти по подстроке нельзя.

          И мне интересно почему они всегда строят деревья вместо возможности заюзать хештаблицы аля мапа слово на позицию.
          Ответить

          • ava bormand 20.04.2014 08:04 # +1

            В постгресе FTS тоже не дает по подстрокам искать. Но там нормализуются окончания, поэтому твой коммент нашелся бы и по фразе "дерево строится". Как в оракуле - х.з.

            > вместо возможности заюзать хештаблицы аля мапа слово на позицию
            Потому что будет слишком дохуя?
            Ответить

            • ava LispGovno 20.04.2014 16:29 # 0

              > Потому что будет слишком дохуя?
              А чем мапа из дерева меньше мапы из хештаблицы?
              Ответить

              • ava bormand 20.04.2014 18:43 # +2

                Ты предлагаешь забить все куски всех слов в эту карту? Там же будет твориться ёбаный квадратичный пиздец ;)))

                Поэтому в том же постгресе сделано так:
                select to_tsvector('хуй, пизда и джигурда');
-- 'джигурд':4 'пизд':2 'ху':1
                И индекс строится уже по нормализованным словам. И ищет более-менее мягко, и индексы не так уж пухнут, как если в них забивать все-все-все куски...
                Ответить

                • ava LispGovno 20.04.2014 18:46 # 0

                  > квадратичный
                  Чё это вдруг? Чем хештаблица не устроила то?
                  Ответить

                  • ava bormand 20.04.2014 18:49 # 0

                    Блин, давай пока отложим хештаблицы и деревья, и сформулируем то, что ты будешь в них пихать?

                    Что во что твоя карта будет отображать?

                    P.S. Я не особо шарю в кишках GiST и GIN индексов ;( Более того, для меня они чорная магия.
                    Ответить

                    • ava bormand 20.04.2014 18:53 # 0

                      Но судя по тому, что у GIN'а сложность растет пропорционально логарифму количества разных слов - это походу и есть то самое древо, отображающее слова в ссылки на записи.
                      Ответить

                    • ava LispGovno 20.04.2014 18:56 # 0

                      > GiST и GIN
                      В гуглокартинках по обоим гуглится такая жопа, что я чуть не проблювался. Особенно от первого.

                      Ладно первое я ещё могу представить. Второе - это что?

                      Допустим все префиксы всех слов мы скидали в хештейбл. Получилась здоровая ёба. Собственно мапим например 'джигурд' на строку таблицы.
                      Ответить

                      • ava bormand 20.04.2014 19:07 # +1

                        > все префиксы всех слов
                        Да нафига они нужны? Это же только дичайше раздует индекс (мелкие префиксы встречаются в дохера и больше строк), да добавит ложных сработок (по слову 'ху' будет искаться и 'хуй' и 'художник' и 'хутор'...). Ну и по серединам слов один хрен искать не будет :(

                        P.S. Надеюсь ты не предлагаешь потом искать все префиксы искомых слов в этой мапе (чтобы по 'художнику' находился 'хуй')? :)

                        Поэтому и выбрали более-менее разумную альтернативу - тупо обрезать окончания у слов. В оракле и M$ может быть и по-другому, надо дождаться d++ или dbdev...
                        Ответить

                        • ava LispGovno 20.04.2014 19:09 # 0

                          Я просто не так выразился.
                          Имел в виду просто слова без окончаний мапить на строку. Я не предлагал строить префиксные деревья или забивать мапу всеми префиксами одного слова
                          Ответить

                          • ava bormand 20.04.2014 19:16 # 0

                            > Имел в виду просто слова без окончаний мапить на строку.
                            Дык постгрешный GIN и sqlite вроде так и делают?
                            Ответить

                            • ava LispGovno 20.04.2014 19:25 # 0

                              Но они делают деревья вместо хештаблиц. Почему?

                              Единственное предположение у меня в том, что часто < нужно делать, но вот в случае поиска подстроки < уже не нужно. Так что это не оправдание, а вот самое главное оправдание видимо рехешинг при расширении. И он видимо дохрена долгий
                              Ответить

                              • ava bormand 20.04.2014 19:41 # 0

                                Ну да, рехеш создает непредсказуемые задержки, что для того же OLTP вообще смертельно. А дерево хоть и помедленней (на случайном доступе, на последовательном оно вклочья порвет хеш из-за i/o), зато распределение задержек более-менее ровное и предсказуемое...

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

                                • ava roman-kashitsyn 22.04.2014 18:42 # 0

                                  > Хотя в этой конкретной задаче локальность вроде как и не нужна

                                  вероятно, индексы лежат на диске, а в этом случае локальность очень даже нужна. Мало кто захочет при изменении одного нода перезаписывать весь индекс целиком.

                                  Я тут как раз just for lulz пишу биграмный поиск на крестах, тема близка :) У меня только in-memory, потому юзаю хэш-таблицы.
                                  Ответить

                                  • ava LispGovno 22.04.2014 19:11 # 0

                                    > биграмный поиск
                                    Поиск в тексте по двум символам?
                                    Ответить

                            • ava LispGovno 20.04.2014 19:26 # 0

                              Так что за GIN? Не гуглится
                              Ответить

                              • ava bormand 20.04.2014 19:29 # 0

                                http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html
                                Ответить

                              • ava bormand 20.04.2014 19:34 # +1

                                http://www.postgresql.org/docs/9.3/static/indexes-types.html

                                А вот здесь все индексы, какие там есть.
                                Ответить

                                • ava LispGovno 20.04.2014 19:39 # +1

                                  |&>
                                  @>
                                  Няшно. Пошел читать.
                                  Питушки мотивируют.
                                  Ответить

                        • ava LispGovno 20.04.2014 19:13 # 0

                          Хотя вот если бы не потребление, то префиксное дерево было бы весьма кстати, если искать по произвольной части слова.
                          Ответить

                        • ava DBdev 22.04.2014 18:26 # 0

                          > и M$ может быть и по-другому
                          Какие-то мапы строят в MS: http://technet.microsoft.com/en-us/library/ms142505(v=sql.105).aspx
                          Ответить

          • ava bormand 20.04.2014 08:11 # +1 

            create table comments (id serial, text text);
insert into comments (text) values ('И мне интересно почему они всегда строят деревья вместо возможности заюзать хештаблицы аля мапа слово на позицию.');
insert into comments (text) values ('В постгресе FTS тоже не дает по подстрокам искать. Но там нормализуются окончания, поэтому твой коммент нашелся бы и по фразе "дерево строится". Как в оракуле - х.з.');
select * from comments where text @@ 'строить дерево'
-- показывает обе фразы
select * from comments where text @@ 'искать подстроку'
-- показывает только мою
            Ответить

      • ava defecate-plusplus 20.04.2014 00:47 # +2

        > в нормальных СУБД по дефолту
        в оракле да, Oracle Text доступен даже в Express Edition, хотя, вроде, раньше имелся только начиная со Standard
        Ответить

      • ava DBdev 22.04.2014 18:24 # +1

        > в нормальных БД он обычно всегда включен по дефолту?
        В MS SQL Server-e полнотекстовой поиск является отдельным сервисом (есть во всех версиях, кроме экспресс), который надо отметить галкой при установке, запускается отдельно от ядра СУБД (хотя часть поиска всё-же есть в ядре). По-умолчанию не включён.
        Ответить

    • ava bormand 19.04.2014 23:40 # +3

      Тем более кутишные запросы вполне умеют в параметризацию.
      Ответить

      • ava LispGovno 20.04.2014 07:38 # +1

        Я более того скажу - они ещё и сами экранируют от скул инъекций, если в параметрах бака. По крайней мере на нормальных БД.
        Ответить

        • ava bormand 20.04.2014 08:15 # +2

          > По крайней мере на нормальных БД.
          На ненормальных тоже норм. По крайней мере кутишный драйвер БД разбирается в экранировке намного лучше юзера :)

          Олсо там есть баг: http://govnokod.ru/12077
          Ответить

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