DBA - русскоговорящее сообщество
Вопросов: 256
Ответов: 2310
Популярные вопросы
от хранения в txt файле каком-нить. Типа логику там с пользователями, язык для запросов можно докрутить поверх txt, а в чем фундаментальное различие? Можете подсказать?
создание TEXT KEY? Primary не вариант, а CLUSTERING нету вроде какхотя и он вроде как не должен работать. P.S. если это нужно, то код идёт под Android на Java + SQLite P.P.S. Я пока начинающий, потому не понимаю как это сделать P.P.P.S. Проблем с производительностью не будет, т.к. максимум будет +- 100-200 элементов
стратегия разрешения конфликтов last writer wins?
|created | --------|--------|-------------------|-------------------| 1| 6|2020-11-16 18:29:30|2020-11-16 18:29:30| 1| 5|2020-11-16 18:29:30|2020-11-16 18:29:30| 1| 4|2020-11-16 18:29:30|2020-11-16 18:29:30| 3| 3|2020-11-16 18:29:30|2020-11-16 18:29:30| 3| 2|2020-11-16 18:29:30|2020-11-16 18:29:30| 3| 1|2020-11-16 18:29:30|2020-11-16 18:29:30| 3| 5|2020-11-16 19:56:33|2020-11-16 19:56:33| как проверить есть ли нужная мне пара в таблице?
окне [string_agg over]? Явная сортировка не поддерживается, но можно ли опираться на то, что неявная будет оставаться постоянной без изменения запроса?
чём их смысл, если я могу все теже самые проверки переборки инпуты сделать в той же java?
точнее комменты Комментарии будут как виджет который используется на двух разных страницах к разным вещам Грубо говоря в таблице комментов должен быть внешний ключ на запись из одной или другой таблицы, это то, к чему привязан комментарий, обобщим и например 1 таблица это видео а другая какая-то галерея и у них обоих есть комментарии Есть идея сделать 3ю таблицу в которой два поля 1 - айди 2 - число по которому можно определить для какой таблицы выше указанное айди является типа внешним ключом Но мне кажется что то, что для самой БД теряется явная связь - является проблемой Это нормальное решение? или стоит подумать еще, либо же кто-то может подсказать? Если нормальное, то как в итоге таблицу то эту назвать?
объяснить что от меня хотят? Не забывай, что сущность – это множество однородных объектов реальных или виртуальных. Сущность ТРУДОВАЯ КНИЖКА – это множество виртуальных объектов, которые представляют записи из всех реальных трудовых книжек всех сотрудников. У одного сотрудника может быть несколько записей в его трудовой книжке.Какой номер труд.книжки впишешь в таблицу Сотрудник, если у него несколько записей в труд.книжке?
других уровней? Если для других, то для каких?
с isolation level = REPEATABLE READ, то блокировка на чтение держится всю транзакцию То есть, если я начинаю транзакцию, вызываю select, а потом update на ту же строку, то в теории должна произойти ошибка т.к. update не может получить лок из-за уже существующей блокировки на чтение?
транзакции. Т.е какая-то будет видна раньше, а какая-то позже. Получается, что не будет атомарности? в какой-то момент можно увидеть только часть изменений
на каком уровне изоляции в PostgreSQL - скажите получается такую ситуацию нельзя наблюдать для PostgreSQL и именно поэтому в доке ничего про это не сказано?
около 10 млн записей, в неё постоянно происходят вставки и обновления, а так же постоянный select к ней с фильтрацией по разным набором полей вот тут и проблемы, индексы делал простой, составной, mysql просто отказывается брать необходимый индекс и берет не эффективный, использовать use index такое себе решение наверное по крайней мере при одних запросах быстро, при других уже нужен другой индекс и угадать селективность сложно и покрыть все комбинации. Может кто сталкивался, аналогия - таблица todo постоянная фильтраций по диапазаону партишены по дате тоже пробовал, представим что надо назначать задачу кому-то и в этих задачах искать по статусам и другим параметрам
разрывает соеденение и перезагружаеться сервер Error 2013: Lost connection to MySQL server during query when dumping table Заметил что такое также при тяжелых запросах которые охватывают большой обьем данных. Лог ошибок пустой, там только инфа что сервер перезагрузился. Или возможно нужно доп логи какие то включить ?... Такое появилось после переустановки mysql, перед этим эти же команды работали - просто долго. Возможно какие то настройки сбились но не знаю в какую сторону смотреть
на выборку по количеству дочек? Например: Есть таблицы users и projects. В таблице projects есть поле user_id. И вот мне надо выбрать 50 юзеров, и у каждого из них что бы были проекты, но не более 20. Но бегать за проектами каждого юзера в базу не очень хочется. Как можно это реализовать за наименьшее кол-во походов в базу?
елементов ?
больше 1 млн строк. Сама таблица представляет из себя нечто следующее: CREATE TABLE my_table id NOT NULL PRIMARY KEY, ... search_title VARCHAR NOT NULL, another_search_field VARCHAR NOT NULL, deleted TIMESTAMP Другие поля просто опустил за ненадобностью в данном вопросе. Так вот, у меня там был обычный составной индекс для search_title, another_search_field. Начал анализировать планировщика запросов и понял, что индексы у меня не используются. Важно уточнить, что у меня в запросах имеется LIKE оператор, т.е это выглядит примерно так: SELECT * FROM my_table WHERE search_title LIKE '%some title%' AND another_search_field = '...'; В общим, анализ EXPLAIN analyze,verbose,timing,costs,buffers мне показывает, что у меня используется последовательный поиск для запроса Запрос: SELECT id FROM my_table WHERE search_title LIKE '%title%' Результат: Seq Scan on public.my_table cost=0.00..40873.66 rows=1052908 width=16 actual time=0.050..7154.845 rows=1053013 loops=1 Output: id Filter: mt_table.search_title::text '%title%'::text Buffers: shared hit=192 read=27519 Planning Time: 0.069 ms Execution Time: 13513.829 ms На всякий случай отключил последовательную прогонку, но в итоге результат всё равно такой, что индекс не используется. Понятное дело, что set enable_seqscan = off не форсит отмену последовательной прогонки. Но, похоже, что других вариантов нет для планировщика. И в том числе нет варианта использовать индекс. Seq Scan on public.my_table cost=10000000000.00..10000040873.66 rows=1052908 width=16 actual time=24.158..7218.534 rows=1053013 loops=1 Output: id Filter: my_table.search_title::text '%title%'::text Buffers: shared read=27711 written=32 Planning: Buffers: shared hit=11 read=5 dirtied=3 written=5 Planning Time: 0.730 ms JIT: Functions: 4 " Options: Inlining true, Optimization true, Expressions true, Deforming true" " Timing: Generation 1.118 ms, Inlining 4.890 ms, Optimization 12.192 ms, Emission 6.884 ms, Total 25.084 ms" Execution Time: 13776.353 ms В итоге подумал, что проблема в том, что обычный индекс тут не особо уместен, попробовал создать GIN индекс. Потому что исходя из моих требований поиск по LIKE все филды текстовые, а значит и уместность, по идеи, должна быть. CREATE INDEX trgm_idx ON my_table USING GIN search_title gin_trgm_ops WHERE deleted IS NULL; Касаемо deleted, то у меня просто используется принцип soft-delete в приложении. Короче, пробую опять. И результат тот же - индекс не используется. В итоге у меня сложилось ощущение, что я что-то упустил. Может GIN индекс тут неуместен? Может тестовые данные у меня не особо подходящие? Про второе следует уточнить, что я нагенерил 1мл записей, где в качестве поля search_title выступает следующий паттерн: UUID title UUID. Т.е условно говоря, должно быть большое кол-во страниц с повторяющимися данными для LIKE оператора. Потому что сейчас, что индекс есть обычный или GIN, что его нет - одна репка, как говорится.