Это действительно самая простая связанная таблица, которую вы можете составить - она применима практически к любой системе баз данных.
Ваша таблица стоимости будет иметь
Id - pk id (все таблицы должны иметь этот PK)
Идентификатор актива - стандартный столбец длинных номеров, используемый для связи с таблицей активов.
пункт (описание стоимости (краска, шины, ремонт сидений и т. Д. И т. Д.)
Стоимость (сумма данного товара)
Таким образом, вы создаете основную форму, основанную на активах, а затем создаете вложенную форму, которая, вероятно, лучше всего подходит как «повторяющиеся строки» или так называемая форма с несколькими элементами (из которой вы переходите в основную форму, и таким образом, форма «затраты» становится подформой активов.
Таким образом, по сути, вы прикрепляете каждую строку стоимости к данной отдельной записи активов. И доступ автоматически установит для вас столбец «Идентификатор актива», если вы укажете форму затрат в качестве дополнительной формы в форме активов.
Форма будет выглядеть примерно так:
Выше (приложение доступа и базовая форма, которую я встроил в Access) у меня фактически есть «два» столбца, в которых можно выбрать тип «элемент» или «стоимость». У меня есть солнцезащитные очки, но в следующем ряду я могу добавить шины, затем покрасить, а потом кого захочу. Со временем вы можете добавить любой «новый» элемент затрат без необходимости создавать новую таблицу или изменять структуру базы данных.
Если ваш дизайн требует «изменения» в структуре таблицы для каждой новой «вещи», которую вы вводите, значит, у вас неправильный дизайн. Можете ли вы представить себе бухгалтерский пакет, который вы должны постоянно «останавливать» и модифицировать программное обеспечение?
И тогда настоящая неразбериха возникает, когда вы пытаетесь создать отчет. Еще раз, отчеты работают только с заранее определенными таблицами - вы можете «переключать» таблицы на лету для отчета.
Так что любая ваша концепция в отношении электронных таблиц и т. Д. Должна быть выброшена из вашего разума. Компьютерные информационные системы ПРОСТО НЕ РАБОТАЮТ В ЭТОМ СПОСОБЕ И НЕ МОГУТ РАБОТАТЬ В ЭТОМ СПОСОБЕ!
Имейте в виду, что реляционные базы данных НЕ являются электронными таблицами, и вы не можете и НЕ МОЖЕТЕ принимать проекты, которые требуют изменения структуры на лету. Формы, отчеты, запросы и даже компьютерный код не могут работать с таблицами, которые изменяются для каждой вводимой вами записи - вы ДОЛЖНЫ принять модель данных, которая отражает ваши текущие потребности. Эту модель данных, если все сделано правильно, ТОГДА можно использовать для очень сложных систем учета, ERP-систем или даже для интернет-магазина, который имеет тысячи или даже миллионы различных продуктов. Сначала создаются такие модели данных, а затем создаются формы и пользовательский интерфейс, отчеты и т. Д.
То же самое касается и стоимости работы. У вас могут быть жидкости, затраты на рабочую силу, обои для ног, краска для галлонов и плитка для метров. Таким образом, так же, как система выставления счетов, системы расчета стоимости работ могут обрабатывать «разные» виды затрат, и никаких изменений в таблице не требуется.
В приведенном выше примере у нас есть счет-фактура, и мы можем добавить столько вещей, сколько мы хотим, к бронированию тура. (Билеты, куртки, книги, коньки, шины, краски, сиденья и окна - все, что мы хотим - мы просто добавляем новую строку для всего, что нам нужно.
Подумайте о любом используемом вами программном обеспечении для выставления счетов - вы можете добавить в этот счет столько элементов, сколько захотите.
Реляционная база данных НЕ поддерживает полностью новую таблицу для каждой новой «стоимости», которую вы хотите построить - простые базы данных не работают таким образом. Таким образом, вам только (пока) действительно нужна главная таблица актива, а затем дочерняя таблица «затрат».
Вы не можете создать совершенно новую таблицу «затрат» для каждого актива, так как встроенные инструменты в любой из всех баз данных не поддерживают и не работают с созданием новой таблицы для каждого нового набора данных, который вы создаете.
А для простоты ввода данных вы могли бы составить таблицу «Предметы затрат», чтобы пользователю не приходилось набирать краски, шины и т. Д., А выбирать этот элемент из выпадающего списка.
Итак, КАЖДЫЙ отдельный пример в Интернете, каждая книга и каждая статьяПростое объяснение того, как связать основную таблицу с дочерней таблицей, действительно на 100% уместно, и именно так вы ДОЛЖНЫ решить эту проблему.
Реляционные базы данных не поддерживают создание совершенно новой таблицы для «одного» нового набора данных, поскольку такой подход не может использоваться в отчетах, а язык запросов не поддерживает такой дизайн.