Ви, схоже, неправильно розумієте сенс реляційних БД. Кожна таблиця має відповідати певній сутності - наприклад, товару, артикулу, накладній і т.д. Якщо одна сутність має якийсь стосунок до іншої - треба додавати зовнішній ключ (foreign key, FK, id іншої таблиці, якщо просто). Бажано, щоб при цьому інформація в БД не дублювалася -  у вас, схоже, має бути завжди залишок+видано = кількість; а це означає, що одне з полів є зайвим - бо можлива ситуація, коли будуть записані всі три значення без такого співвідношення, тобто буде порушення цілістності даних.
У вас є дві таблиці - в одній "видано", в іншій "кількість" та "залишок". Ці "видано" і "залишок" стосується одного об'єкта чи різних? Якщо одного - вони, швидше за все, мають бути в одній таблиці. Якщо ж це різні пов'язані сутності (наприклад, "видано" по кількох накладних, а "залишок" товару на складі) - то треба додати в накладні посилання на товар, і потім робити в запиті JOIN з кількох таблиць чи вкладений запит.

Якщо розкажете, що це і як воно має працювати - може, щось підкажемо.

Змінив зовнішні ключі, додав таблицю, обчислення виніс в одну сутність, поки все працює.
Набиваю дані. Дякую за оперативність!

доречне питання, але інфо від мене було не повне, мені дуже важливі залишки, оскільки це склад і і тут розраховується мін-макс, загалом система працює на 1С, але так безглуздо, що дістати якусь адекватну потрібну інфу неможливо, а оскльки БД еволюціонує, мені не вистачає даних, тож я вибрав один із її сегментів і пробую реалізувати на невеликій кількості записів свої маленькі задумки)))))

Про який білд йде мова ?
Переглянув свої debug-білди (на C++, C#), не знайшов там надлишкової інформації. Вся інформація, яка там сидить, є (або може бути) необхідною для дебагу програми.

Якщо ви про інформацію, яка не попадає в release, ну так на то він і debug-білд, щоб тримати купу додаткових даних.

Сильна заява. Перевіряти я її, звичайно, не буду. Але якось не віриться.

Власне, ідея несуперечності даних якраз у тому і полягає, що в базі не може бути неправильних даних.
Хоча кешування теж річ потрібна, не сперечаюся. Головне - чітко розуміти, де первинні дані, а де кеш.

Як ви взнаєте де баги, не маючи можливості порівняти поточні дані з якимись іншими у базі? Наприклад з якимись контрольними сумами? Контольні суми, як і будь-який інший вид дублювання інформації, мав би відкидатися під час нормалізації бази. Але з чим тоді порівнювати?

Вони усі уже давно звільнилися, і успішно передали свої "напрацювання" вам. А ви лише через місяць зрозуміли, як насправді усе погано, і шукати винних було уже пізно.