|
|
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Еще некоторые не слишком длинные поля переменной длины можно хранить в специальном кодировании (см. UTF-8), чтобы не нужно было хранить их длину отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 17:11 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Nutz, мне кажется ты не уедешь далеко на такой постановке. Неясно очерчены ограничения. Получается что строку не более 128 символов сохранить можно. А если такую-же строку+ дату? Что тогда? Ошибка или урезать строку? А если архивировать текст? А справочник архиватора - внутри считывающего устройства. Или это невозможно? А можно на документ 2 РФИД метки наклеить? И тогда будет в сумме 512 байт. А нельзя вообще в метке хранить только ID а другие атрибуты в базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 17:44 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Кстати, а может просто метки другой марки использовать. Насколько я вижу в поиске, они бывают и по 2 Кбайта, и даже по 8 Кбайт. Тут уже и графика полезет или даже содержимое самого документа :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 17:51 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
7 бит - тип данных, текст (1) или не текст (0). Если текст, то следующие 7 битов кодируют длину (до 127 символов). Текст и массив байтов одно и то же. В 6 бите кодируется признак специальных данных, если 1, то в последующих 6 битах можно закодировать либо 6 логических атрибутов (архив, служебное, оригинал, ценное), либо до 64 значений. Либо их комбинацию. Если биты 7 и 6 не установлены, то установленный 5 бит означает, что в битах с 0 по 3 кодируется тип данных (число, дата, валюта и т.д., до 16 типов). Бит 4 может быть зарезервирован и остается еще 4 бита (с 0 по 3) для дополнительной информации. Но вообще в данном случае я склоняюсь к тому, что оптимальным будет хранить ID и простой текст, без структурирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 19:15 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Вы уж решите, вам важнее простота/читаемость в будущем или плотность хранения. Усидеть на двух стульях сразу не получится. Если второе - то это проприетарный бинарный формат, со сжатием, экономией битов и прочими извращениями. Через 30 лет читаться это не будет, также, как сейчас не читаются бинарные файлы Excel 3.0 c русским текстом в DOS-кодировке внутри, созданные на экселе для древнего макинтоша. И вряди ли вы запишите в вашу метку что-то настолько ценное, чтобы потомкам в виндовс-2033 захотелось писать разборщик вашего бинарного формата. Который опять же вы должны будете тщательно задокументировать и сохранить. Гибкость и удобство разбора ниже плинтуса, но впихнуть сможете максимум, хоть и ценой адового труда. Если первое - то однозначно простой текст, в однобайтовой ASCII-кодировке, только английский текст или транслитерацию. Из служебных данных для книг однозначно стоит вписать ISBN, штрих-код и название/автора. Пример формата: ISBN:9783161484100;EAN13:2400000032639;Year:2013;T:3;Auth:L.Tolstoy;Name:Voyna i mir;На идиотские школьные задачки про экономию сферических битов в вакууме забить оптом, писать простые, понятные и легко разбираемые форматы данных. Кстати, строчка выше заняла всего 86 байт. У нас ещё и запас остался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 23:46 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Nutzwadman, UID - в 7 байтов у этой метки уже есть. Он конечно может храниться в базе. Но какой срок жизни этой базы? Она может сгинуть через несколько лет. А исторический документ хранится в архиве десятки и сотни лет. RFID-метка может быть живой 30-40 лет. Поэтому важно впихнуть в нее максимум информации. Даже если база пропадет, чтобы что-то можно было вытащить из метки.Глупости какие. Если у тебя пропал каталог библиотеки, но остались сами книги с rfid-метками то сделать новую метку на книгу основываясь на обложке книги - никаких проблем не составляет. И просто и надежно. А если ты будешь восстанавливать каталог на основе тех "умных" меток которые ты описываешь, то ты рискуешь получить полную чушь в восстановленном каталоге. Кто гарантирует что одна метка не отклеилась не прицепилась по ошибке к чужой книге? Кто гарантирует что это не было сделано специально вороватым читателем? Единственное для чего эта метка годится это для хранения кода который будут знать твои сканер+база. Без них rfid бессмыслен. Но и сама метка, без книги на которую эта метка налеплена, так же бессмыслена. А информации о книге в самой книге всегда больше чем в какой-либо метке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 01:45 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
miksoftОбщие рецепты: 1) Часть полей, наличие которых обязательно (например, дата документа, количество страниц и т.п.) для всех документов и формат которых допускает запись фиксированной длины, располагать в начале и не сопровождать мета-информацией. 2) Строковое поле переменной длины расположить в конце и тоже не сопровождать мета-информацией, даже длиной. Лишние байты записывать фиксированным содержимым, например, нулями. 3) Для строк использовать сокращенные алфавиты в 6-7 бит. Можно, кстати, и дробное количество бит. Например, пару символов кодировать 13 битами. 4) Если алфавит использует не все возможные комбинации битов, то можно не хранить длину, а использовать определённую комбинацию битов как терминатор строки. 5) Можно строго документировать тип и порядок максимально возможного набора полей, но хранить не все, а только реально заполненные. Для всех необязательных для заполнения полей хранить маску битов для обозначения факта наличия поля. Потенциально, так можно будет сэкономить на указании типов полей. Ага, а через тридцать лет кто-нибудь найдет эту метку, подберет, расшифрует и покачает головой: "А ведь когда-то к этой метке была приклеена вот такая толстая книга... Наверное в этой книге было что-то интересное." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 01:48 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
nsclЕсли первое - то однозначно простой текст, в однобайтовой ASCII-кодировке, только английский текст или транслитерацию. Из служебных данных для книг однозначно стоит вписать ISBN, штрих-код и название/автора.Нафиг это все не нужно. Метку без сканера не прочитать. Сканер без базы не бывает. А значит все что нужно это внутренний код базы. Берешь используемый каталогизатор, смотришь как там сделан первичный ключ на тома и повторяешь его в метке. Если оригинальный ключ не лезет в 128 байт - делаешь суррогатный: GUID или даже row_id. Все. nsclНа идиотские школьные задачки про экономию сферических битов в вакууме забить оптом, писать простые, понятные и легко разбираемые форматы данных. Кстати, строчка выше заняла всего 86 байт. У нас ещё и запас остался.Биты не сферические, они квадратные. Так в учебнике нарисовано :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 01:55 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
maytonNutz, мне кажется ты не уедешь далеко на такой постановке. Неясно очерчены ограничения. Получается что строку не более 128 символов сохранить можно. А если такую-же строку+ дату? Что тогда? Ошибка или урезать строку? А если архивировать текст? А справочник архиватора - внутри считывающего устройства. Или это невозможно? А можно на документ 2 РФИД метки наклеить? И тогда будет в сумме 512 байт. А нельзя вообще в метке хранить только ID а другие атрибуты в базе? 2 метки клеить нельзя, потому что дорого и повышает риск повреждения документа в будущем, когда метка будет меняться но новую. ID и сейчас храниться в базе данных. Точнее ее аппаратный UID. Проблема в том, что один UID в базе слишком ненадежный способ хранения информации о фонде. База данных может быть уничтожена в результате пожара, стихийного бедствия или диверсии сотрудников. В этом случае все метки разом станут бесполезны. Нужно заново вводить всю информацию в базу, а если у вас в фонде 10-15 миллионов единиц хранения? Годы уйдут на восстановление. Поэтому возникла идея, хранить еще и название документа и дополнительные поля данных. В случае утраты базы, сотрудники берут ручные считыватели, и сканируют книги с определенной полки, даже не прикасаясь к ним. За один проход можно собрать информацию о тысячах единиц. UID книги, ее название и т.д. Затем все эти данные сливаются с ручного считывателя в базу данных и переходим к следующей полке. И таким образом можно быстро восстановить информацию о фонде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 09:42 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
White OwlЕсли у тебя пропал каталог библиотеки, но остались сами книги с rfid-метками то сделать новую метку на книгу основываясь на обложке книги - никаких проблем не составляет. И просто и надежно. Если у тебя 10 книжек то проблем не составляет. Но даже в средних по-размеру библиотеках книг могут быть миллионы. И каждую нужно найти, снять с полки, отнести к компьютеру, вручную вбить ее данные в базу, отнести назад, поставить на полку. Это годы работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 09:56 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
nsclЕсли первое - то однозначно простой текст, в однобайтовой ASCII-кодировке, только английский текст или транслитерацию. Из служебных данных для книг однозначно стоит вписать ISBN, штрих-код и название/автора. Пример формата: ISBN:9783161484100;EAN13:2400000032639;Year:2013;T:3;Auth:L.Tolstoy;Name:Voyna i mir;На идиотские школьные задачки про экономию сферических битов в вакууме забить оптом, писать простые, понятные и легко разбираемые форматы данных. Кстати, строчка выше заняла всего 86 байт. У нас ещё и запас остался. Идея хорошая. Но проблема в длинных названиях книг. Что делать если оно не помещается в метку? Ваш вариант почти занимает всю доступную память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 10:43 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
NutzЧто делать если оно не помещается в метку? Ничего не делать. Если у книги есть ISBN, другие данные нужны только для контроля и удобства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 11:09 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
NutzБаза данных может быть уничтожена в результате пожара, стихийного бедствия или диверсии сотрудников.Есть такие термины- "катастрофоустойчивый хостинг", "катастрофоустойчивый ЦОД" и т.п. Рекомендую обратить внимание на профессиональные решения в этом направлении. То, что вы сейчас пытаетесь изобрести, это фактически самопальная реализация катастрофоустойчивой БД. Которая будет заведомо хуже. Конечно, для собственного успокоения вы можете сохранить часть информации в самих метках, но это, имхо, даже не полумера, а однадесятаямера. В дополнение к меткам не забудьте заложить на хранение в разных местах несколько партий полных комплектов оборудования для считывания меток. Учтите, что через 30 лет большей части современных интерфейсов просто не будет в обиходе. И каждые несколько лет нужно будет пересматривать и пополнять хранимое оборудование новым, чтобы к нужному моменту можно было собрать стенд, чтобы информацию с меток передать в современное на тот момент оборудование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 11:52 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
miksoftВ дополнение к меткам не забудьте заложить на хранение в разных местах несколько партий полных комплектов оборудования для считывания меток.И софт не забудьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 11:57 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
В целом, все вышеописанное Nutz - придумываение проблем на ровном месте. Какие пожары, наводнения и ядерные войны? Что быстрее повредится в случае катастрофы - сам фонд, метки, или БД, существующая хотя бы в 2-3 копиях (можно даже в твёрдых )? Да и "диверсии сотрудников и читателей" быстрее будут направлены на книги, нежели на защищенную БД. Так что, как я уже и упоминал - используйте метки только по их прямому назначению, и не изобретайте велосипедов с квадратными колёсами... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 15:11 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
AndreTMв 2-3 копиях (можно даже в твёрдых )Кстати, насчет твердых копий - существуют аналоги QR-кодов для печати на лист А4. По моим предположениям, твердая копия базы в такой форме будет стоить порядка стоимости одного винта и по массе переносима одним человеком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 16:58 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
NutzПроблема в том, что один UID в базе слишком ненадежный способ хранения информации о фонде. База данных может быть уничтожена в результате пожара, стихийного бедствия или диверсии сотрудников.Глупости-глупости-глупости. Для сохранения баз существуют бэкапы. Для сохранения бэкапов существуют вторые бэкапы в других зданиях. Особо параноидальные фирмы хранят свои бэкапы в других городах и на других континентах. Потерять базу это чрезвычайно сложное дело, если конечно ваша контора об этом побеспокоилась заранее - и похоже ваша контора таки беспокоится заранее. Диверсия сотрудников - не давайте доступ к бекапам для простых смертных и не обижайте админов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 20:07 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Если там подшивки газет или протоколы то ISBN у них может отсутствовать. Да и вообще... было-бы полезно всё бумажное оцифровать. Исключение пожалуй-бы составили документы имеющие нотариальную ценность или исторические манускрипты. А всё остальное под сканер и в топку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 20:41 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
maytonА всё остальное под сканер и в топку.Прогрессор хренов ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 21:47 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Отнюдь. Я декадент и классик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 22:02 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
maytonОтнюдь. Я декадент и классик.Тогда вы должны понимать, что единственная адекватная замена книги - микрофиша. Уменьшенная оптическая копия каждой страницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 22:06 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
maytonисторические манускрипты. А всё остальное под сканер и в топку.Насколько я понял топикстартера, документы либо уже уже имеют историческую ценность, либо ожидается, что будут иметь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 22:11 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
Насколько я понял это каталогизация архива. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 22:15 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
maytonНасколько я понял это каталогизация архива.да, за последние 500 лет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2013, 22:22 |
|
||
|
Впихнуть структуру произвольных данных в 128 байт
|
|||
|---|---|---|---|
|
#18+
miksoftmaytonНасколько я понял это каталогизация архива.да, за последние 500 лет.Окститесь, для документов хотя бы и столетней (не говоря уж о двухсотлетней и далее) давности отнюдь бы не "придумали клеить на них метку". Что-то мне начало всё это напоминать попытку развода/распила/подъёма ценника... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2013, 00:52 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38224246&tid=1341850]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 484ms |

| 0 / 0 |
