Al_BЕще можно добавить поле пересчета суммы к какой-либо "эталонной" валюте
Я бы постарался избежать понятия "эталонной" валюты. Практика недавнего прошлого показала, что ее довольно неприятно менять на ходу эксплуатации системы.

Al_BА вот одна таблица и для прихода, и для расхода - очень не советую. Потому что......
Имхо эти подходы в целом эквивалентны, и решение действительно стоит выбирать исходя из конкретики. Варианты:

1. Одна "широкая" таблица с некоторым количеством "иногда незаполняемых" полей

2. Одна таблица "общих полей" и некоторое количество "расширяющих таблиц", содержащих специфику конкретных типов документов и привязанных к общей один к одному

3. Несколько разных таблиц и вьюха/вьюхи, объединяющие общие поля из них в единый список

в принципе позволяют решить одни и те же задачи. Лично мне наиболее симпатичен второй вариант, но в зависимости от специфики (сколько общих полей, насколько похожи разные документы, что удобнее для используемых инструментов), думаю, можно построить примеры "best suited" ситуаций для каждого из вариантов.

Al_BНу вроде бы на территории РФ рубли пока что никто не отменял ;)
Не отменял. В них просто никто не считает :))

Al_BВ любом случае даже при "замене" евро обратно на доллар проще будет сделать одно обновление по одному курсу,
Э-э, это далеко не одно обновление по одному курсу. В известном мне случае это полтора месяца напряженной работы. Только первый приходящий в голову пример - старые документы с их "эквивалент ... по курсу ...".

Al_Bчем пересчитывать это по очереди из рублей, тенге, гривен и т.п.
Хм. Думаю, насчет количества пересчетов в каждом случае поспорить можно, но не нужно :) Ограничусь следующим: моя позиция состоит в том, что "сразу сделать хорошо и потом спокойно спать по ночам" куда приятнее, нежели "сделать быстро, а потом срочно переделывать как надо". Эталонная валюта с моей точки зрения этому подходу не соответствует. Впрочем, в любом случае тут решать автору топика.

Al_BСложности могут начаться при ......
Безусловно. В то же время есть достаточно инструментов, чтобы противостоять этим сложностям - то же партиционирование. Вообще говоря, если у нас есть набор таблиц и (может быть, если нужна) объединяющая их вьюха, мы можем заменить их общей таблицей (с именем вьюхи) и модифицируемыми вьюхами (с именами таблиц) так, что наш программный код этого практически не заметит. Сложности точно так же могут возникнуть и с разнесенными документами, например, нужно будет помнить все места, куда нужно внести дополнения при появлении очередного типа документов (очередной таблицы). Например, часть кода мы будем вынуждены тупо отдублировать, либо писать динамический sql с подстановкой имен таблиц. Ну а триггера - так точно дублировать. А если у них еще и основные поля по-разному называются... Кстати, тоже болезнь - если есть пятьдесят однотипных таблиц, в одной-двух поле PRICE будет написано с грамматической ошибкой, и неопытный руководитель может поддаться на "ну пусть так останется, не переписывать же то, что уже есть". Ну или например "документом-основанием для документа X могут быть документы следующих 8 типов" - с разными таблицами это бизнес-правило реализуется не очень комфортно.

Именно поэтому я предпочитаю подход под номером два: свести подобные части документов в одну общую таблицу, а специфику разнести по расширяющим. Это несколько усложняет "простой" DML (редактирование документов), но позволяет наиболее естественно и удобно прописать бизнес-логику, в том числе обойтись без кучи проверок на тип документа, необходимых при "черезчур универсальной" таблице.