Как реализовать базу данных / таблицу как стек

У меня есть конечный автомат, который должен выдвинуть / выдвинуть некоторые имена файлов для разных пользователей. Я бы традиционно использовал стеки в качестве выбора структуры данных, но это нужно делать с использованием базы данных, поскольку у меня нет способа сохранить структуру данных между входящими веб-запросами.

Мне было интересно, что было бы хорошим способом реализовать функциональность стека с использованием баз данных?

Мне нужно поддержать:

push (имя_файла, пользователь): нажать имя_файла для пользователя
pop (пользователь): выталкивает самое верхнее имя файла для пользователя

РЕДАКТИРОВАТЬ :

Я прототипирую идею, и поэтому я использую sqlite3 с python.

Спасибо!

database-design database-recommendation

— brainydexter
источник

Ожидаете ли вы, что один и тот же пользователь будет иметь несколько одновременных подключений? какие объемы? какой дб двигатель тоже пожалуйста?

— ГБН

@gbn В конце концов, один и тот же пользователь может иметь одновременные соединения. Но сейчас я

— создаю

@brainydexter Мне бы очень хотелось узнать, что вы пытаетесь сделать. У меня такое ощущение, что вы можете создавать неправильное решение вашей проблемы. Возможно, вы захотите рассказать нам о своей проблеме и найти лучший способ ее решения. Реализация стека в виде таблицы базы данных звучит как плохая идея.

— ксенотеррацид

@xenoterracide: общая цель того, что я пытаюсь сделать в SO: stackoverflow.com/questions/5145051/… Стек не работает полностью, поэтому я все еще ищу решение этой проблемы.

— Brainydexter

@brainydexter не очень удивлен, SQL - ужасный язык для реализации стека, потому что по реляционному определению набор неупорядочен, поэтому у вашего стека не будет порядка, и вам придется его отсортировать. Возможно, частью вашей проблемы является то, что вы говорите людям, каким хотите получить ответ, и спрашиваете, как это сделать. Вместо того, чтобы говорить им, в чем проблема, и спрашивать, в чем. Даже ваш ТАК вопрос приводит ответ к чему-то конкретному. Попробуйте попросить решение, о котором вы не будете думать.

— ксенотеррацид

Ответы:

Если вы спрашиваете о том, какую базу данных использовать, это действительно зависит от личных предпочтений и того, что вы хотите от этого. Поскольку я только знаком с MySQL, я отвечу на другую часть вопроса, предполагая MySQL:

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

Что касается дизайна таблицы, кажется, вам действительно нужна только одна таблица:

CREATE TABLE `wordpress`.`<table_name>` (
`id` smallint(4) NOT NULL AUTO_INCREMENT UNSIGNED,
`user` varchar(30) NOT NULL,
`filename` varchar(255) NOT NULL,
`date_insert` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE `userFile`(user, filename)
) ENGINE=`InnoDB`;

Я выбрал произвольный столбец 'id', установленный в, AUTO_INCREMENTпотому что первичный ключ реплицируется в каждой записи каждого индекса. Таким образом, выполнение первичного ключа (user, filename) может вызвать проблемы с производительностью, если ваши имена файлов очень длинные.

Размер вашего столбца 'id' зависит от того, насколько большой будет расти ваша таблица. Неподписанный Smallint даст вам 65 тыс. Строк.

Пользователь и имена файлов varchar, потому что они будут сильно различаться по длине, я полагаю.

Это date_insertпросто способ упорядочить ваши результаты в зависимости от того, когда они были вставлены (полезно для вашего POP)

— Дерек Дауни
источник

Я думал о том, чтобы сделать (id, user) комбинацию в качестве первичного ключа, так как я хотел бы нажать или выдвинуть на основе пользователя. Что вы думаете ? Кроме того, для операции POP не было бы лучше найти запись для пользователя с максимальным идентификатором?

— Brainydexter

@brainydexter dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html имеет некоторые ограничения на автоинкремент (в некоторых редких случаях он будет использовать «более низкие» значения автоинкремента). потому что это возможность, я пошел с полем date_insert. Что касается использования (id, user) в качестве первичного ключа, нет никакого смысла, кроме как занять больше места. Идентификатор уникально идентифицирует строку. просто «пользователь» сам по себе не идентифицирует строку, поэтому вы можете просто иметь неуникальный индекс для «userID» вместо уникального (user, filename), если хотите.

— Дерек Дауни

Если вы рассматриваете базу данных Oracle, вам следует рассмотреть возможность использования расширенной очереди с шаблоном очереди LIFO (последний пришел первым вышел) .

На самом базовом уровне очереди один производитель помещает одно или несколько сообщений в одну очередь. Каждое сообщение снимается с производства и обрабатывается один раз одним из потребителей. Сообщение остается в очереди до тех пор, пока потребитель не удалит его из очереди или не истечет срок действия сообщения. Производитель может указать задержку до того, как сообщение станет доступным для использования, и время, по истечении которого сообщение истечет. Аналогично, потребитель может подождать при попытке удалить сообщение из очереди, если сообщение недоступно. Агентская программа или приложение могут действовать как производитель, так и потребитель.

— Ли Риффель
источник

классический производитель / потребительская установка. Спасибо за информацию, я буду иметь это в виду.

— Brainydexter

Надеюсь, MySQL получит некоторую функциональность Adance Queue теперь, когда Oracle «владеет» mysql ...

— Дерек Дауни

@DTest: конечно, существует также явная вероятность того, что в MySQL теперь меньше шансов получить расширенные функции, поэтому Oracle может различать бесплатное программное обеспечение и то, за которое вы должны платить.

— Джо

@ Джо, спасибо, что испортил мои выходные с этой мыслью!

— Дерек Дауни