я предлагаю хранить так:


| ID матрицы | ID столбца | ID строки | Значение элемента |

Достоинства: полная независимость от размерности, все операции над матрицей прекрасно выполняются простыми селектами/апдейтами

вторая запись не вставится, т.к. будет нарушение уникального индекса, а для тех, кто не догадается сделать индекс уникальным, или констрэйнт повесить - будет то ли одна запись, то ли одна, но определитель неправильный будет, то ли будет восприниматься как (0,0,0,44), смотря от того, как выборки делаться будут

p.s. в матрицах обычно нулевых столбцов/строк не бывает

в продолжение темы для хранения N-мерных матриц предлагаю следующую структуру:

1) таблица элементов:

| ID элемента | Значение элемента |

2) таблица координат элемента:

| ID матрицы | номер измерения | номер элемента в измерении | ID элемента |


таким образом двумерная матрица

6 71
21 45

будет храниться так:

1)

1 6
2 71
3 21
4 45

2)

1 1 1 1
1 2 1 1
1 1 2 2
1 2 1 2
1 1 1 3
1 2 2 3
1 1 2 4
1 2 2 4

Man555 _bob ..или констрэйнт повесить

на сколько мне известно constraint вовсе не для этого предназначен. в данном случае корректнее было бы использовать триггер (идеологически это не то же самое) ;-)

В ответ на PS можно подлить масла в огонь и сказать, что для тех, кто привык к С-подобным языкам нумерация с 0 даже естественнее. так что вопрос спорный ;-)

насчёт новой структуры. допустим такую ситуацию

6 0 0
0 0 0

будет храниться так:

1)

1 6

2)

1 1 1 1
1 2 1 1

какой размерности матрица? Ведь совсем не 2x2, хоть и измерений 2. Зато это можно будет узнать, если хранить ВСЕ 0 (то же справедливо и для варианта для | ID матрицы | ID столбца | ID строки | Значение элемента | ), а в случае больших разряженых матриц объёмы и временная сложность подскочит. Таким образом, это решение всего-лишь добавляет возможность хранить N-мерных матрицы, но проблему до конца не решает.

Критика? :-)

а для чего используется unique constraint как не для обеспечения уникальности?

привыкшие к С-подобным языкам при обработке матриц пользуются литературой, которую написали не привыкшие к С-подобным языкам, вот в этой литературе нумерация начинается с 1 независимо от того кто к какому языку привык

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

какой проблемы структура не решает? проблема была одна: хранить матрицы в БД

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

а вот что демагогию интересно читать и на неё отвечать мне совсем не кажется

к Вашим претензиям могу добавить, что стремящиеся к бесконечности и нулю величины хранить в числовом поле вообще не получится, но это мало кого останавливает :-)