>>197
>結合とか、余計な機能使ったら、遅くならないの？？

>>196　の例ならば、たいして遅くならない。
select　
　Z.品目コード,　H.名称,　Z.数量 * H.単価
from
　在庫テーブル Z　left join　品目情報テーブル H
　on
　Z.品目コード = H.品目コード ;

在庫テーブルも品目情報テーブルも、品目コードがプライマリキーであることは明らかだから、結合キーが品目コードだけの上記SQLは十分速い。

>在庫テーブルと、品目情報テーブルを読み込んで、
>在庫の一覧表テーブルを、新しく作れば良くない？？

良くない。そんな事する方が圧倒的に遅い。

誤解しないで欲しいのだが、俺は別にSQL結合マンセーではない。場合によっては、>>197 の主張するとおり、中間的なテーブルを設けて処理する方法もアリだと思う。しかし、>>196 のような単純な例では、
　中間テーブル方式 ＞＞＞＞ SQLで必要情報を結合して取得する方式
コストを比較すればこうなる。

もし、在庫一覧表出力機能あるいはそれに類する物を設計する機会があるなら、中間テーブル方式にせよ、SQL結合方式にせよ、状況（データ構造、更新頻度、etc）によって適切な方式を選択する必要がある。
しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、無条件に中間テーブル方式を採用してしまうような気がする。技術者として、その姿勢にはいささか問題があるよ。