Табличная бд, вопрос: как читать данные?

Question

[rsk ii]

есть данные которые надо записать координаты (x;y) в таблицу.
пример таблицы:
| |1|2|
|1|x|Y|
|2|C|v|
вопрос: возможно ли читать данные спрашивай x и y (например 1;2 = C)?

Comments

[Алан Гибизов]

В принципе можно получать строку таблицы по номеру строки, а потом получать значение по порядковому номеру ячейки в строке.
Но тут надо предпринять специальные меры, чтобы порядок колонок всегда был одинаков; формально можно в таблице расположить колонки как вам надо и затем получать их по запросу select * from mytable; однако это не гарантировано - всё-таки порядок колонок штука, важная только для визуального удобства оператора таблицы, а для вычислений оно в реляционных БД не предусмотрено.
Можно поименовать колонки с индексом в названии, но всё это такое костылестроение…

Важный вопрос: для чего вам это надо? Если появилась подобная задача, есть подозрение в неправильном пути решения задачи или неверном понимании задачи.

[Алан Гибизов]

Вот что значит не зашоренный взгляд. Василий Банников, красавчик, легко придумал решение.

Но всё-таки, rsk ii! Зачем?

[rsk ii]

Алан Гибизов, это просто эксперимент

Answer 1

[Василий Банников]

Сделай обычную таблицу с колонками x, y, value и делай запрос SELECT value FROM table_name WHERE x = ? AND y = ?;

А ещё то что ты хочешь очень похоже на Excel, только там в качестве координаты по горизонтали используются буквы, а не цифры.
Но при этом преобразование координаты из десятичного числа в "номер" колонки в Excel - это операция, которую легко сможет сделать школьник, который не прогуливал информатику и помнит, как преобразовывать любое число из 10-чной системы счисления в n-ричную.

UPD:
Но если заполнены обязательно все клетки, то тогда дешевле будет хранить это как непрерывную последовательность символов в файле и брать значение по сдвигу.
Это при условии, что значение в каждой клетке имеет длину в 1 символ.
Но вообще если добавить больше конкретики - можно придти к наиболее оптимальному решению.
Спасибо Алан Гибизов за напоминание, что программирование не только лишь про веб и реляционные бд.

Comments

[Алан Гибизов]

А и верно! Так просто…
Правда, накладные расходы в виде x y индексов добавятся… но действительно, сработает. Не знаю, зачем это надо… но прикольно!

[Василий Банников]

Алан Гибизов, если у автора очень много будет пустых клеток, то переплата за индекс легко перекроет плату за хранение пустоты.
Но если заполнены обязательно все клетки, то тогда да - дешевле будет хранить это как непрерывную последовательность символов и брать значение по сдвигу.

[rsk ii]

спасибки сэр

Answer 2

[mayton2019]

Колонки нельзя называть цифрами. Обычно дают имена начиная с латинских букв. id, c1, c2 например.
тогда
SELECT c2 WHERE id = 1
выдаст
C
Вообще твой вопрос не про базы данных а про матрицы в программировании. По крайней
мере ту картинку что ты нарисовал в чистом виде в БД никто не кладет.

Comments

[Slava Rozhnev]

Колонки нельзя называть цифрами.

Было бы желание: https://sqlize.online/sql/psql14/d6765314fc3284d99...
:)

[mayton2019]

Slava Rozhnev, вам придется проверить все диалекты SQL для всех DBMS дорогой друг.

[Slava Rozhnev]

mayton2019, согласен, хорошая тема для исследования!

Answer 3

[rPman]

Чтобы ответить на вопрос 'как хранить?', нужно задаться вопросом 'как будешь искать и читать?'.

Типовой вопрос - нужен ли порядок в строках и колонках? не спроста ведь ты колонки и строки назвал цифрами. Беда в том что sql не очень эффективно работает с упорядоченными данными (там O(n) = n*log(n) трудоемкости с оговорками) и для того чтобы строки упорядочить, нужно будет либо хранить дополнительное поле для сортировки (иногда хватает pk id с autoincrement но до тех пор пока записи не удаляешь)

Так же есть вопрос на многопользовательский (точнее одновременный в несколько сессий) доступ к данным на запись (или запись + чтение). Наличие такого требование значительно поднимает сложность задачи, sql базы для этого предлагают транзакции и блокировки.

Следующий вопрос, нужно ли искать/сортировать по значению. И отрицательный ответ на этот и предыдущий вопрос могут вообще дать ответ - не пользуйся sql.

Универсальный способ хранения матриц переменной размерности это таблица, где каждая запись - одно значение ячейки, с полями (int x,int y,value) где x,y - номер колонки и строки соответственно. Этот же метод самый неэффективный, особенно когда таблицы большие.

Таблицы маленького фиксированного размера (колонок), при отсутствии необходимости тосовать порядок колонок в запросе, можно хранить как есть, по одной строке матрицы в строке базы данных, в таблицах (y,x1,x2,x3,x4,x...) где x1,x2,x3 это значение колонок с номерами 1,2,3 соответственно а y - номер строки