Таблица базы данных Oracle для ведения журнала активности пользователя веб-приложения
Я хочу вести полный журнал активности всех действий, совершаемых пользователем в моем веб-приложении. Я сделал несколько таблиц, чтобы помочь мне сделать это, и наткнулся на этот вопрос: Мне нужно хранить относительно длинный текст только в одном столбце. Является ли это хорошей практикой и использование varchar2 (2000), например, также является хорошей практикой? У меня будет около одного-двух миллионов записей.
@thatjeffsmith нет, этого не произойдет, потому что веб-приложение запрещает пользователям вводить больше символов даже в интерфейсе. Я задаю вопрос с точки зрения: «Хорошо ли хранить такие данные столбца для одного миллиона записей?».
знаменитые последние слова, все начинают думать, что никто не получит доступ к их данным за пределами своего приложения ... вы всегда можете увеличить его до 4k или 32k позже. и не должно быть проблемой. проблема в том, что вы будете делать с этими данными позже — вам нужна индексация по ключевым словам? посмотрите, например, текст оракула
@thatjeffsmith хорошо, я новичок во вселенной Oracle, и это рабочая задача. Самое главное — следить за всем, что исходит от пользователей. Так, например, у нас есть раздел «Комментарии» в Web-приложении. Нам нужно сохранить эти комментарии в базе данных. Ежедневный трафик составляет около 200 комментариев. Каждый комментарий может содержать около 400 символов. Это просто пример, но, как я уже сказал, я новичок, и это задача, ха-ха...
Я думаю, что вы на правильном пути, если вы видите, что в среднем 400, хранить как 2k звучит разумно. хотя всегда есть крайние случаи..
Ответы 1
С одной стороны, с объемом памяти в базе данных все в порядке. Поля VARCHAR2 занимают столько места, сколько требуется фактическим данным, поэтому, если у вас есть только 100 символов, в базе данных будет использоваться только пространство, необходимое для этих 100 символов.
С другой стороны, когда вы читать извлекаете данные из базы данных, вы можете столкнуться с проблемами. Поскольку программа, читающая данные, не знает, сколько символов фактически хранится в каждой строке, она может выделить полные 2000 символов пространства, чтобы при переносе данных из базы данных в память программы это пространство было доступно. Для двух миллионов записей это составило бы около четырех гигабайт памяти, если бы все эти строки считывались в память одновременно.
Сжимая руку, у вас может не быть особого выбора. Если вам нужно хранить строки символов этой длины в столбце, сделайте столбец VARCHAR2(2000) (или 4000, или до 32 КБ в более новых версиях Oracle). Просто знайте о потенциальных проблемах и не удивляйтесь, если возникнут проблемы с памятью. Помните, железо дешевое, время программиста дорого.
(Кстати, мем «одна рука/другая рука/сжимающая рука» взят из книги Ларри Нивена и Джерри Пурнелла «Соринка в глазу бога». Если вы поклонник научной фантастики и не читали ее, вам следует :-).
большое спасибо за ответ. У меня есть идея, когда данных станет около 1 млн записей, я перенесу их в лог-файлы и освобожу от этого Oracle и сервер. Спасибо за книгу, это будут хорошие выходные, если я найду ее на своем местном рынке. Кстати, я все еще новичок в Oracle, поэтому, если мои идеи сумасшедшие или глупые, это от недостатка опыта.
1M записей - это НИЧТО ... это хорошее начало, и оно будет работать, отлично масштабируется в вашей базе данных оракула.
@thatjeffsmith: здесь Я опубликовал небольшой разглагольствования о «дешевом оборудовании / дорогом программисте». Это (своего рода) юмористическое 20-секундное чтение, но я думаю, что правильно понял — безумно низкая стоимость оборудования (я настолько стар, что помню, когда компьютеры стоили реальные деньги и правил IBM — так что стреляйте в меня...) устранение проблем с производительностью с помощью оборудования более рентабельно, чем заставлять разработчиков тратить дни и недели на то, чтобы все работало быстрее. Компании не делают этого, потому что никто не «видит» затраты на заработную плату и льготы.
@BobJarvis, так чего не хватало в моем ответе? ;)
@thatjeffsmith: текст жирный и выделен курсивом. И ЗАГЛАВНЫХ - нужно МНОГО-МНОГО ЗАГЛАВНЫХ! :-)
как только вы сделаете это 2000 символов, кто-то откроет ошибку, которая не может хранить 2001 символ. обратитесь к своей модели данных. какой там текст? есть ли БИЗНЕС определение для этих данных? допустимо ли хранить там, скажем... миллион символов? если это так, рассмотрите вместо этого CLOB