| 1.1, fleonis (ok), 11:26, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 ух ты, а я и не знал про session - пришлось делать свой велосипед. сделал кучу тригеров, чтобы велась история :)
| | |
| |
| 2.4, chinarulezzz (ok), 14:15, 19/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 а я крутил педали через связку с inotify)
Справедливости ради, session только в этом релизе появилось. Как можно было знать?
| | |
| |
| 3.7, ананим.orig (?), 18:01, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
а надо было через fanotify
> $ man fanotify
> fanotify - отслеживание событий в файловой системе
> ОПИСАНИЕ
> Программный интерфейс fanotify уведомляет о событиях в файловой системе и перехватывает их. Например, его можно использовать для сканирования…
> Дополнительные возможности по сравнению с программным интерфейсом inotify(7): способность отслеживать все объекты в смонтированной файловой системе, давать права на доступ и читать или изменять файлы перед тем как доступ получат другие приложения.
как-то так.
| | |
|
|
| 1.2, vn971 (ok), 12:36, 19/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 fleonis, ещё для некоторых видов данных прокатывает подход "никогда не менять строки в БД, только добавлять новые". Типа, если надо что-то изменить, то добавляешь новый элемент с обновлённым временем. Если нужно получить значение - берёшь наиболее новый элемент.
Прокатывает, прямо скажем, не всегда. Но при этом иногда хорошо ложится на монгу/кассандру.
| | |
| |
| 2.3, Аноним (-), 13:46, 19/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Прокатывает, прямо скажем, не всегда.
Не прокатывает, очевидно, когда записей больше 100?
| | |
| |
| 3.5, Crazy Alex (ok), 14:49, 19/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Чепуха. Для тех же биллингов это штатый режим работы, а уж там-то строк поболе будет. Но не SQLite, конечно.
| | |
| |
| 4.6, _ (??), 17:16, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Чепуха. В том же биллинге только resource use log так работает, остальное - нет.
| | |
| |
| 5.8, Crazy Alex (ok), 18:23, 19/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
В тех, что я видел - так работало всё - от финансов (само собой) до состояния файрволла. UTM тот же.
| | |
|
| 4.9, Аноним (-), 18:35, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Для тех же биллингов это штатый режим работы
Да как хоть?! Оно ж таким макаром тормозить должно через пару месяцев/лет работы! :(
| | |
| |
| 5.12, Аноним (-), 03:25, 20/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
с денормализацией (хотя бы через material views) и партиционированием - не должно
| | |
|
|
|
| 2.10, Аноним (-), 22:13, 19/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
Именно этим первые социальные сети объясняли то, что их данные не исчезают даже после удаления.
| | |
| |
| 3.15, Аноним (-), 18:01, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Именно этим первые социальные сети объясняли то, что их данные не исчезают
> даже после удаления.
Потому что там не идиoты разрабатывали. Ну-ка, попробуй удалить - даже с использованием индекса - одну строку из таблицы 100 млн строк. И-да, учти, это _маленькая_ таблица, а даже не средняя.
Вставлять строки - дешево, выбирать - по B-tree индексам - быстро, а удалять - дорого песдетс.
Что вам, краем уха слышавшим, о RDBMS, еще объяснить?
| | |
|
| |
| 3.16, Аноним (-), 18:01, 21/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> При этом уникальные ключи становятся неуникальными и прочий головняк
Это смотря кто пишет.
Ошибка всегда в генах, вопрос лишь - в чьих.
| | |
|
|
|
