virtuOSMS SQL.
Как правильно спланировать БД для фиксации заявок от пользователей? Если рассмотреть самый простой случай, когда каждой заявке присваивается номер и есть некий набор обязательных полей для заполнения. У пользователей будут права на внесение изменений в уже заведенные заявки. Также требуется видеть историю изменений, вносимых пользователем по заявке.

Самый важный вопрос здесь - как это все будет использоваться?
Как часто нужно видеть внесенные изменения , и как именно - нужно ли будет реализовывать откат изменений и т.д. и т.п.

Если редко / просто вываливать изменения списком:

основная - idTicket, createdByUser (idUser), ...params..., modfiedByUser (idUser), modifiedStamp.
PK - ( idTicket )

история - idHistory (identity), idTicket, createdByUser (idUser), ...params..., modfiedByUser (idUser), modifiedStamp, action ('I','U','D').
PK - ( idTicket, modifiedStamp ) / idHistory
Если ненулевые шансы, что могут по одному idTicket сабмитить данные чаще раза в секунду - однозначно idHistory.

и триггеры:
after insert/update -> inserted.*, 'I'/'U' -> history
after delete -> inserted.*, 'D' -> history

Почему нужно триггер на DELETE? Да чтоб можно было откатить случайно удаленную запись :)

softwarerskyANAПрактика говорит о том, что не надо выдумывать и опасаться.

К примеру в Jira у пользователей есть права на внесение изменений в уже заведённые заявки,
но не видел чтобы кого тянуло использовать данный инструмент по той идиотской схеме, что Вы описали.
Вы будете смеяться, но последние лет пятнадцать каждый раз, когда на sql.ru заходит речь о разрешении пользователям редактировать свои посты, именно эта "идиотская схема" упоминается как решающий аргумент против.
Извините, но это "идиотский аргумент"... Причина - лень, а остальное - тлен.

vmagВы лучше вдумайтесь в то что вы написали....
Давайте по Кэролу.
Я прекрасно вдумываюсь в то, что пишу, потому что если я это написал - оно было измышлено и продумано. Я мог измыслить и написать, но не продумать, но я так не делал. Более того, измышленное, продуманное и написанное мной я прочитал, продумал еще раз и измыслил, что написано вдумчиво.

vmagА как делать откат того, что уже сделано физически по заявке ???
Приводить заявку к факту того, что уже сделано физически - и есть смысл реализации этих заявок в ИС.
Например, статус, какие-то детали, сроки исполнения. А может пользователь создал ее по ошибке и хочет удалить - да пожалуйста. Задача разработчика не сказать, что это идиотизм, а максимально обезопасить такой функционал от случайностей. В том числе если пользователь-таки прострелил себе колено. Вот и придумали максимально простой способ - при внесении изменении сохранять все предыдущие данные, а еще лучше - дублировать. Новыми заменять основную таблицу, и параллельно вносить данные в историчную с меткой времени и другими сервисными параметрами.

Насколько я понимаю, Issues на github реализована по такой схеме - по крайней мере визуально именно так, а под капот я не заглядывал.

vmagЕсли изначально был пшик... то хоть маслом его намажь, он пшиком и останется...
Самое обидное, что вот вся эта хрень сейчас лезет в гос порталы и т.д. а народ потом не может
разобраться что к чему, где голова где хвост и вообще о чем речь изначально была...
В чем проблема изменять данные и хранить историю - кроме религиозных предрассудков? У каждого инструмента есть область применимости - и есть список pro и cons применения. Если кто-то приводит в качестве аргумента фразу "потому что это идиотизм" без реального списка - я буду называть этого кадра "идиотом".

И при чем здесь хранение истории и госпорталы - непонятно.

Мое мнение, проблема госпорталов в том, что они делаются людьми низкой квалификации - начинающими/студентами/индусами. Но я вот смотрю на сайты и вижу, как они прогрессируют, что говорит о том, что те, кто их делал растут в квалификации (ну или их заменили на более квалифицированных).

Дело делается, бабло пилится, народ постепенно получает нужный функционал. А если вам не нравится реализация - дело ваше. Для ретроградов, например, есть МФЦ и режим "одного окна". Мне, отстоявшему сотни очередей, госпорталы нравятся больше.
Считаете, что можете лучше, и прямо брызжете альтруизмом - идите в "прикормленные" конторы работать за бесплатно.