Хранение матриц в базе данных
Хранение DateTime в базе данных
В таблице определен столбец типа DATETIME, через DataRow я успешно получаю, устанавливаю его.
Хранение данных вида m*n в базе SQL
Есть задача вести учёт некоторых характеристик товаров. Характеристик этих может быть много (они.
Система бронирования билетов, хранение мест в базе данных
Здравствуйте, работаю над программой бронирования билетов, нужно при нажатии на кнопку проверять.
Хранение данных пользователя(инф-ию,ограничений,разрешений) в Базе Данных, нужен совет
Здравствуйте, подскажите пожалуйста в какой форме лучше хранить в БД информацию о пользователях, их.
Сообщение было отмечено как решение
Решение
Cелена, не разу не доводилось делать, но мысль такая.
Нужно содать таблицу:
1) ID(int), 2) Ширина(int), 3) Высота(int), 4) Массив (Image) [тип Image — позволяет хранить последовательности байтов]
В проге перегоняешь свой массив в байты, и сохраняешь в БД.
При считывании с БД создаешь массив по размерам ширина*высота, конвертируешь обратно байтовый массив
Сообщение от Cелена
Cелена, валерьянка тут при том, что обработка массивов в спец.полях — веселое дело. По крайней мере в постгресе. (исходя из собственного опыта)
А так, храните массивы в БЛОБ полях как Вам и предлагали. Или есть какая-нибудь особенность?
Я когда хранил матрицу смежности графов использовал простую таблицу, тем более, что ее проще обрабатывать:
> x,y,значение + возможно вариант таблицы
Что же касаемо спецполей Постгре — они весьма сложны в обработке SQL запросами
вот пример из документации:
| name | pay_by_quarter | schedule |
| Bill | < |
|
| Carol | < |
Ну, дальше нет смысла постить документацию.
Скачайте PostgreSQL, вполне подойдет версия 8.3.15. Поставьте и поищите в справке.
Кстати, вполне хорошая замена всем платным СУБД. Советую попробовать
Как хранить матричную информацию в MySQL?
Я работаю над приложением, которое анализирует сходство музыки. Для этого я обрабатываю аудиоданные и сохраняю результаты в txt файлах. Для каждого аудиофайла я создаю 2 файла, 1 содержит и 16 значений (каждое значение может быть следующим: 2.7000023942731723), а другой файл содержит 16 строк, каждая строка содержит 16 значений, как показано ранее.
Я хотел бы сохранить содержимое этих двух файлов в таблице моей базы данных MySQL.
Моя таблица выглядит так:
чтобы добавить содержимое этих двух файлов, я думаю, мне нужно использовать тип данных BLOB:
Мой вопрос в том, как хранить эту информацию в базе данных? Я работаю с Java, где у меня есть двойной массив, содержащий 16 значений (для файла1) и матрицу, содержащую информацию file2. Должен ли я обрабатывать значения как строки и добавлять их в столбцы в моей базе данных?
4 ответа
Надеюсь, что я не получаю отрицательный ответ, забвенный этим сумасшедшим ответом, но я стараюсь думать нестандартно. Мой первый вопрос: как вы обрабатываете эти данные после потенциального запроса? Если бы я делал что-то подобное, я бы, скорее всего, использовал нечто вроде matlab или октавы, которые имеют определенную нотацию для представления матриц. Это в основном куча текста с запятой и точкой с запятой с квадратными скобками в правильных местах. Я бы сохранил только строку, которую мое математическое программное обеспечение или модуль может анализировать изначально. В конце концов, это не похоже на то, что вы хотите сделать какой-то запрос на основе точки данных.
Я думаю, вам нужно нормализовать схему, подобную этой, если вы намерены сохранить ее в реляционной базе данных.
Похоже, у вас есть таблица матриц, которая имеет отношения «один ко многим» со своими файлами.
Если вы настаиваете на одной денормализованной таблице, один из способов сделать это — сохранить имя файла, его автора, имя его матрицы и его позицию в строке и столбце в названной матрице, которая ее владеет.
Просьба пояснить одно: это матрица в смысле линейной алгебры? Математическая сущность?
Если да, и вы используете только матрицу целиком, то, возможно, вы можете сохранить ее в одном столбце как blob. Это по-прежнему заставляет вас сериализовать и десериализовать строку или blob каждый раз, когда она входит и выходит из базы данных.
Я думаю, что проблема, с которой сталкивается dedalo, заключается в том, что он работает с массивами (я предполагаю, что один из них зубчатый, один — многоразмерный), и он хочет сериализовать их для blob.
Но массивы не являются непосредственно сериализуемыми, поэтому он спрашивает, как это сделать.
Самый простой способ сделать это — перебрать массив и построить строку, как предложил Дейв и сохранить строку. Это позволит вам просматривать содержимое из значения в базе данных, а не десериализовать данные всякий раз, когда вам нужно их заблокировать, как указывает duffymo.
Если вы хотите знать, как сериализовать массив в BLOB. (это просто кажется излишним)
Что касается того, какой тип данных хранит его, как в MySQL, есть только четыре типа blob для выбора из:
The four BLOB types are TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB
Выбор лучшего зависит от размера сериализованного объекта. Я бы предположил, что BLOB будет достаточно хорошим.
Форум пользователей MySQL
Насколько мне известно в Maria DB появился механизм для работы с графами (OQGRAPH).
А чем, к слову, Вам не нравится идея сохранения пар смежных вершин?
#3 23.07.2011 17:35:27
Re: Как хранить матрицу в БД
Про Maria DB — огромное спасибо.
На счет не нравится — это слишком сильно сказано. Я просто иду другие варианты для хранения и пытаюсь узнать в каких случаях они могут быть более эффективны.
Ведь принимая во внимание, что в для простого графа матрица смежности симметрична и состоит только из <0,1>возможно есть смысл использовать для ее хранения методы для разряженных матриц
#4 23.07.2011 17:40:25
Re: Как хранить матрицу в БД
Хм. Ну, всяческие хитрые форматы типа разреженно-строчного — у них же своя структура, свои массивы, и нет нужды хранить всю матрицу целиком — можно хранить в базе эти самые определяющие матрицу массивы.
А графы, в которых мало ребер я бы хранил скорее в списках смежности 
.
MySQL как лучше хранить матрицу
Доброго времени суток! Подскажите пожалуйста, как лучше хранить двумерный массив? Суть в том, что у меня в базе должны хранится карты высот. Каждая карта представляет собой двумерный массив размерностью 720*720.
Я почитал советы — некоторые предлагают для хранения массива использовать отдельную таблицу. Но у меня таких записей будет порядка 5000 штук. Как-то наверное много таблиц получится.
Конечно самый простой вариант хранить данные в тексте. Но парсинг текста требует много времени. Может кто еще что посоветует?
Заранее огромное спасибо!
Решить это можно только отталкиваясь от того какие и как ты будешь запрашивать данные, и как их обрабатывать.
В MySQL как не храни — будет костыль.
Настоящие СУБД умеют тип данных массив:
Спасибо большое за ответ! В базе хранится дата и матрица. Пользователь запрашивает карту за определенную дату. Т.е. за раз будет запрашиваться только один массив.
Спасибо большое за ответ! К сожалению задание нужно реализовать на SQlite
Ну так SQlite это даже не MySQL. Тогда пили таблицу:
[id], [matrix_id], [X], [Y], [value]
и храни всех свои массивы в одной таблице, выбирай по matrix_id и получишь значения только для нужной тебе матрица. А данные пусть там хранятся, как им угодно.
Интересная идея, сейчас попробую реализовать. Спасибо огромное!
Пользователь запрашивает карту за определенную дату. Т.е. за раз будет запрашиваться только один массив.
Как вы любите придумывать всякую байду — я просто поражаюсь вашей сообразительности.
Берёшь сишку и дампишь свои 5000*720*720 в файлец, тебе даже индекс не нужен, потом читаешь за 1сискол. Это а) в мильён раз быстрее твоей любой бд, б) в тысячи раз проще/надёжней. в) не нужно пилить стопицот кастылей для такого ущербства, как db.
А теперь подумай, что является лучшим выбором: три строчки на сишке + сискол, либо хренпоймичто какая-то бд+стопицот тысяч строк.
5000*720*720 это около 2,4 Гб 🙂 Я понимаю память дешевая, но слышать такие советы от человека, который предлагает быстрый, минимальный си как-то даже не смешно 🙂
Хм, а в бд они будут занимать ещё больше места. Если ты говоришь про оперативу — перечитай мою месагу и укажи где там говорится про оперативу.
Читаешь не весь файл, если ты об этом подумал, а по оффсету(man read(), lseek(), etc), который ты можешь вычислить без индекса. Читаешь ты ровно 720*720, что требует 720*720 оперативы( что является минимум, меньше которого без тормазов ты не получишь нигде).
Читаешь не весь файл, если ты об этом подумал, а по оффсету(man read(), lseek(), etc), который ты можешь вычислить без индекса.
Поясни человеку, зачем ему заново писать то, что давно реализовано в самых примитивных СУБД в сто раз лучше? Кроме того, надо заранее закладывать возможно безболезненно добавить фичи. Завтра он захочет найти среди своих карт высот какие-то определённые точки — что ж ему, на сишечке опять изобретать то, что даже sqlite умеет? ))
Непонятно каким боком тут скулайт. Положи все матрицы в разные файлы двоичным потоком в максимально естественном формате и не парься.
В сто раз лучше? Это тебе в школе рассказали?
Даже 10% перфоманса моих 3-х строк твоя самая лучшая субд не даст, поэтому с этим ты можешь только соседям по парте пристовать.
Да, напишет на сишке, ибо это займёт у него минут 5 времени и 1000% перфоманса скулайта, а на чтение мана скулайта он потратит полчаса, плюс запилить надо + разобрать выхлоп скулайта, что отнимит у него минимум час.
Поэтому, не рассказывай мне про свои анскильношаблоннные предрассудки из детсада, а говори что-то поделу.
Обычно оп видит задачу далеко и может сам понять надо ему скуль или нет. Но он сюда не за этим пришел. А алгоритмы произвольного доступа к записи в файле есть в начале любой книжки по сям/паскалю, не надо мистичности нагнетать на доступ по индексу.
А еще он потратит время на конверсии скулайт -> си-значение, так бережно сэкономленное на парсинге текста 🙂
Скуль тут вообще ни к месту, план натуральный, индекс естественный, сортировки нет.
Угу, я на это указал вот тут: «разобрать выхлоп скулайта».
Ну это ООП головного мозга и вера в скулайт.
Поддерживаю. Тут еще можно будет кеширование в памяти или mmap использовать для полной оптимизации.
Ты толком не описал структуру данных для одной записи. Думаю там координаты вообще хранить не надо. Х=i / row_size, Y=i % row_size. Где i — порядковый номер записи.
Вроде как человеку нужен одновременный доступ к 5000 координат (или неодновременный; ТС кстати не пояснил эту деталь). Так что пусть думает сам 🙂 Но твое решение тоже неидеально, хотя и имеет массу приемуществ.
Тем не менее, мапить файл рано или поздно придется, когда внезапно понадобиться 50 000 или 100 000 координат. А мапинг уже не один сискол 🙂
Вроде как человеку нужен одновременный доступ к 5000 координат (или неодновременный; ТС кстати не пояснил эту деталь). Так что пусть думает сам 🙂 Но твое решение тоже неидеально, хотя и имеет массу приемуществ.
Без разницы какой, хоть 100500ременный. Оно идеально, ибо лучше не запилить.
Тем не менее, мапить файл рано или поздно придется, когда внезапно понадобиться 50 000 или 100 000 координат. А мапинг уже не один сискол 🙂
Не имеет смысла, хоть там мильярд координат, да и на этом загнётся бд.
Распреденная БД не загнется
Ну работать будет да, отдавая по 100мапов в секунду — это не есть вменяемая работа.
Ну тут либо шашечки, либо ехать, хоть как-то. А вообщея с твоей мыслью согласен. Модель данных у ТСа не реляционная, забивать гвозди микроскопом причин не вижу.
Без разницы какой, хоть 100500ременный.
Ну ты тролль. Еще раз 5000 * 720 * 720
Засунь каждую карту в отдельный файл. Так будет со всех сторон проще.
От блин нахрен, у меня есть десяток теребай, а у него нет — ну да.
Ещё раз, если ты не осилил read() и lseek() — это твои проблемы. Читает он 720 * 720, хоть 100500гигов у тебя будь.
В любом случае у тебя будет занимать это 5000 * 720 * 720, что ты мне этим хочешь сказать?
Засунь каждую карту в отдельный файл. Так будет со всех сторон проще.
По реализации в коде может и проще, но тогда автор получит 5000 файлов. Нафига это нужно? Лучше уж либо read + seek заюзать, либо BLOB в SQLite, чтобы все данные в один файл слить.
Ключевое слово BLOB. BLOB это потоковое значение, фактически файл.
1. По себе людей не судят.
2. Я говорил про ОЗУ, а не место на МЖД.
2. Я говорил про ОЗУ, а не место на МЖД.
А причем тут ОЗУ? Как в моём описании в ОЗУ появится 2.4гига — это лишь в твоих мечтах
НЖМД если так уж охота выпендриться.
Ты правда не понимаешь, что файл можно читать не с начала и до обеда, а с любого места по любое? Или ты решил рассмотреть гипотетическую ситуацию загрузки вообще всех матриц в память одновременно, и уверен, что БД тебя в этом случае магически спасет?
Тем не менее, мапить файл рано или поздно придется, когда внезапно понадобиться 50 000 или 100 000 координат
Лол, просто девелопмент не для тебя, братиш.
Лучше бы ты кресты так рекламировал, а то у меня уже отвращение к голому си появляется из-за адептов.
Старая BDB не сможет дать такой throughput, т.к. не может синкать отдельные записи. А без синка база обречена внезапную смерть. А с синком будут ощутимые тормоза (только по сравнению с обычными файлами, естественно). От синка данных может спасти журнал, который в новых версиях, но тащить этого оракловского монстрика ради записей в файле, я делаю хм.
Если запись редкая, а чтение частое, то стандартная и везде в наличии BDB 1.85/1.86 на BTREE или RECNO может быть очень хорошим решением.
Это будет последние, что я сделаю в своей жизни.
А что с адептами нитак? Реальные адепты сишки просто не любят юзать 10к строк на то, что можно сделать 3-мя.
автор получит 5000 файлов. Нафига это нужно?
1) экономия на спичках. Что такого в 5тыщ файлов?
2) гораздо проще для обновления. У тебя имя файла это нужная дата.
В общем, не надо все данные в один файл сливать.
Ломаются и тормозят файловые системы вроде нтфс, а также переполнение глоббинга в shell со товарищи. Можно поделить на директории по тыще штук, тогда везде будет ок.
реальные адепты не будут с пеной у рта доказывать что-то недоучившимся и людям в процессе обучения, а тихо-мирно подскажут направление и все, посадив семя знаний и наблюдая как растет ЧСВчеловек. А тремя и на баше можно писать.
2ТС: Я бы тоже в файле сделал, так как БД, по мнению моей логики следует пихать для списков всяких. Но, возможно, я не прав — учусь сам
а также переполнение глоббинга в shell со товарищи
Это уже давно не актуально.
Можно поделить на директории по тыще штук, тогда везде будет ок.
Здравая мысль. Причём, можно разбить по дням/месяцам и получится что-то типа индекса. Заодно можно будет удобно удалять старые данные.
Дак я сказал нормально, что я не вижу смысла в том, что писали до меня.
А уже тот спор поднял не я, а всякие доказыватели мне их ООП истин, поэтому зачем ты на меня гонишь? Я лишь написал объективно самое простое, быстрое и надёжное решение.
Нинай, у меня греп вот что выдает:
А вот здесь почти везде счет идет на десятки килобайт. Хотя в рамках задачи это не актуально, согласен.
Причём, можно разбить по дням/месяцам и получится что-то типа индекса. Заодно можно будет удобно удалять старые данные.
Но зачем городить такой велосипед если есть SQLite? Табличка с матрицами + сколько душе угодно табличек с метаданными (если и когда будут нужны) и не нужно заморачиваться с созданием папок, подсчётом количества файлов в папке и разруливанием проблем с файловыми системами, если таковые появятся (а с файлами в несколько десятков гигабайт вроде все ФС легко справляются).
разруливанием проблем с файловыми системами, если таковые появятся
о каких таких мифических проблемах вы все говорите? Кстати, а sqlite вообще repair database есть?
о каких таких мифических проблемах вы все говорите?
1) Фрагментация из-за большого кол-ва мелких файлов. Как результат — замедление скорости доступа к данным на HDD накопителях (тут всё зависит от конкретной ФС и её особенностей).
2) Некоторые ФС плохо работают с большим кол-вом небольших файлов, т.к. дописывают кучу метаинформации. На ЛОРе были даже были темы про это (искать лень, было год или полтора назад вроде). Получим оверхед по размеру данных пропорционально количеству файлов.
3) Придётся писать свой велосипед, пусть и небольшой. А, следовательно, искать и править в нём баги. В случае использование элементарного SQLite часть багов за нас уже выловлена и пофикшена (особенно учитывая то, что Firefox юзает SQLite, а, следовательно, «тестеров» у SQLite более чем достаточно). Лично мне лень тратить своё время на решение данной задачи. Зачем? Есть уже готовое решение, да ещё и протестированное.
Кстати, а sqlite вообще repair database есть?
Если я правильно тебя понял, то предлагается делать это через .dump. Примерно так: http://www.ibiblio.org/elemental/howto/sqlite-backup.html
Если я тебя неправильно понял, то поясни, что ты имел ввиду под repair database.
1) а база данных, стало быть, не будет фрагментироваться? А ничего что она тоже файл?
2) «некоторые ФС плохо работают с большим кол-вом небольших файлов» — ты что, издеваешься? Ну не используй эти «некоторые ФС». Или тебя насильно заставляют ставить какой-нить фат16? Все основные ФС отлично работают с 5тыщ файлов. В продакшене я следующие ФС видел/использовал: рейзер3, xfs, ext2, ext3, ext4, jfs, tmpfs.
3) Путь ТС сам выбирает как ему удобнее. Но вот у меня нет никаких проблем написать «велосипед» из 10 строчек:
Если я правильно тебя понял, то предлагается делать это через .dump.
В том-то и дело что ты говоришь про «ненадёжность фс», а сам никогда не восстанавливал битую sqlite-базу.
1) а база данных, стало быть, не будет фрагментироваться? А ничего что она тоже файл?
Тут я неправильно выразился. В случае с одним файлом — дефрагментация спасёт мир, но если их куча мелких, то данные могут быть размазаны по всему разделу несмотря на профедённую дефрагментацию.
Все основные ФС отлично работают с 5тыщ файлов.
Это сейчас у автора ровно 5к файлов. Но никто не гарантирует, что их не станет больше или меньше (тут ни ты ни я не можем сказать, что будет, т.к. не знаем полностью задачи). Лично моя позиция — лучше не юзать россыпь файлов, т.к. это, потенциально, может доставить проблем.
Путь ТС сам выбирает как ему удобнее.
Согласен. Каждый из нас всёравно выберет то, что ему удобней использовать.
В случае с одним файлом — дефрагментация спасёт мир
Увы, для самой мейнстримовой ФС дефрагментатора вообще нет. А так тут три нюанса:
1) виндовые дефрагментаторы, например, умели в том числе дефрагментировать свободное место.
2) у меня есть сомнения что проблемы производительности вообще актуальны. 1) при данных объёмах всё легко закэшируется в оперативе 2) нам ничего не известно о запросах. Может старые данные будут редко запрашиваться. 3) может там два запроса в день прилетает