|
|
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
добрый день. хочется хранить разреженную матрицу, причем кол-во столбцов меняется хоть редко, но рантайм. простейший способ: [row, column, value] всем хорош, кроме одного - слишком длинная таблица в базе получается, возможно падение производительности. вариант [row, number, value1, value2, value3...., value10] уже лучше. где 23-й столбец лежит в value3 у записи, у которой number == 2. но при некоторых условиях (несколько значений в сильно разбросанных столбцах) получиться еще хуже, когда такая агрегированная запись будет создаваться на хранение одного единственного числа. вариант [row, number1, value1, number2, value2....., value10] - можно хранить, ну примерно сколько нужно (ну в 2 раза больше;), хотя бы не в 10 раз), но в таком случае я не представляю как на sql написать запрос - "хочу все строки, где значение столбец_33 больше 5". есть ли какие-то общепринятые идеи на этот счет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 17:33 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufa всем хорош, кроме одного - слишком длинная таблица в базе получается, возможно падение производительности. Для начала имхо хорошо бы определиться, какие операции будут с этой матрицей, а потом уже смотреть, возможно ли там падение производительности, какое и на чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 17:39 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
пустых строк не будет. столбцы заполнены произвольно, но в большинстве случаев кучно. заполненные номера столбцов: [1,3,4,5,7], а не [1,1000,1300,450001] размер - порядка 10000 значений в день. соответственно или 10000 строк для варианта [row, column, value] или во сколько-то раз меньше, если пытаться таблицу растянуть вширь. операции: вставка) поиск всех чисел по номеру строки поиск номеров строк по условию больше, меньше на определенный столбец подсчет строк, у которых заданный столбец not null. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 18:09 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufaпорядка 10000 значений в день. соответственно или 10000 строк для варианта [row, column, value] Соответсвенно миллиона 3 за год. До миллиарда - 300 лет. Где ты увидел "слишком длинную таблицу"? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 18:21 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufaпоиск номеров строк по условию больше, меньше на определенный столбец подсчет строк, у которых заданный столбец not null. Если в этих операциях в условии будет всегда один столбец, т.е. не будет чего-то вроде Код: sql 1. То в схеме (Row, Column, Value) тормозить особо нечему при любом количестве строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 18:27 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufa хочется хранить разреженную матрицуВместо рассуждений о вашем способе решения проблемы неплохо бы посмотреть на саму проблему. Ничто не ново под луной, так что возможно кроме разреженой матрицы есть еще подходы. 17dufa всем хорош, кроме одного - слишком длинная таблица в базе получается, возможно падение производительностиПри сборке строки. А также невозможностью использовать СУБД для проверки целостности данных. Вся эта скучная работа или ложится на прикладного программиста или игнорируется на радость поддержки. Если вы скажете свою выбранную СУБД возможно подобрать СУБД зависимое решение - JSON, XML или еще чего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 20:21 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
признаюсь честно, у меня чисто теоретические подозрения. более чем могу ошибаться с "слишком длинной таблицей" субд назвать не могу, так как коммерческая тайна))) в том плане, что на одной установке это будет MS SQL, на другой Oracle, на третей Firebird, далее везде чего забыл сказать, нужен еще и join. запрос типа такого: select outer_table.* from outer_table inner join matrix on matrix.row = outer_table.id where matrix.column = 55 and matrix.value > 70 and outer_table.date >= '01.01.2015' and outer_table.date < '01.04.2015' - что-то типа "выбрать всех ненормальных по 55 столбцу за квартал". для matrix [row, column, value] и размера matrix в 10 миллионов ничего сильно страшного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 20:36 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufaу меня чисто теоретические подозрения. Тогда не беги впереди паровоза, решай проблемы по мере их наступления, которое может и не случиться. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 21:39 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
Произвольная СУБД, произвольная структура - безумству храбрых поем мы песню ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 21:43 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
это я согласен. это мощное колдунство. но все-таки совсем все шишки собирать собственной головой не обязательно, можно и с более опытными людьми посоветоваться. все-таки, предыдущий запрос с join на 10 миллионах - предположительно не должен вызвать проблем? прозвучал порядок в миллиард - на него и ориентироваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 21:58 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
17dufaдобрый день. хочется хранить разреженную матрицу, причем кол-во столбцов меняется хоть редко, но рантайм. простейший способ: [row, column, value] всем хорош, кроме одного - слишком длинная таблица в базе получается, возможно падение производительности. Ничего страшного не будет. Никакого падения. Если конечно делать правильно и не делать ошибок. На самом деле это -- вообще ЕДИНСТВЕННЫЙ вариант решения такой задачи (как указано выше), поэтому у тебя только два варианта дальнейшего развития событий: -- делаешь этот вариант правильно, и он работает быстро, -- делаешь этот вариант неправильно, и он работает медленно. Неправильно -- это неправильно создаёшь индексы и неправильно пишешь запросы. А структура БД -- единственный вариант, другого просто нет. 17dufaвариант [row, number, value1, value2, value3...., value10] уже лучше. где 23-й столбец лежит в value3 у записи, у которой number == 2. но при некоторых условиях (несколько значений в сильно разбросанных столбцах) получиться еще хуже, когда такая агрегированная запись будет создаваться на хранение одного единственного числа. вариант [row, number1, value1, number2, value2....., value10] - можно хранить, ну примерно сколько нужно (ну в 2 раза больше;), хотя бы не в 10 раз), но в таком случае я не представляю как на sql написать запрос - "хочу все строки, где значение столбец_33 больше 5". есть ли какие-то общепринятые идеи на этот счет? Это всё -- нарушения 1НФ, грубая ошибка проектирования БД. Да и тупо работать на SQL с этой таблицей ты нормально не сможешь. Ни индексы создать, ни искать по этим value2...valueN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 22:02 |
|
||
|
разреженная матрица
|
|||
|---|---|---|---|
|
#18+
спасибо, понял. вопрос закрыт, пошел делать;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 22:14 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=22&tid=1540607]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
35ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 231ms |
| total: | 388ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...