アカウント名:
パスワード:
ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが納められているかを区別するための列が設けられている
後半部は兎も角、前半部(=1つのテーブルで済ます)は、通常のSQLデータベースでもそういう使い方することあるよ殆どのフィールドを検索条件に用いることがあって、しかもテーブル全部見ないといけない検索をする時はそれが一番速いから設計としては美しくないかもしれないけど、実用上はそのほうがいい、ってことはある
自分が見た中で一番酷かったのは、おそらくシステムの拡張への対応を手抜きするためだったんだろうけ
POSレジの伝票テーブルで1レコードに128カラムも項目があって、行番0がヘッダレコードになっていて、明細項目が行番1以降にずらずら並んでいる。1伝票処理するのに馬鹿でかいレコードを複数処理しなければならない上に、ストアドプロシージャで簡単には処理できないデータ形式だったんで、大した処理ではないのにステップ数ばかりが増える。その上開発言語がVB2だったから地獄だった。
> 行番0がヘッダレコードになっていて
EXCELシート?
もちろん、そのシステムにはEXCELシート出力機能がありましたよ。ACCESS版も作ったしVB4,VB5,VB6まで順調にアップグレードしていきました。メモリイーターで困ったシステムでしたよ。DBとランダムアクセスファイルとの違いが分かっていない人が設計すると、ミドルウェアでの扱いに困るDBを平気で設計するのは困ったものです。かたくなにそっちの方が高速だって信じてましたからね。趣味で、まともなDB設計に変更して、C#で1000分の1のステップ数でより高速な互換システム作って、デモを経営陣に見せたら、やっとその担当は首になりましたけど、迷惑な話です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
1テーブルに全部格納するのは時として必要 (スコア:5, 興味深い)
後半部は兎も角、前半部(=1つのテーブルで済ます)は、通常のSQLデータベースでもそういう使い方することあるよ
殆どのフィールドを検索条件に用いることがあって、しかもテーブル全部見ないといけない検索をする時はそれが一番速いから
設計としては美しくないかもしれないけど、実用上はそのほうがいい、ってことはある
自分が見た中で一番酷かったのは、おそらくシステムの拡張への対応を手抜きするためだったんだろうけ
Re: (スコア:0)
POSレジの伝票テーブルで1レコードに128カラムも項目があって、行番0がヘッダレコードになっていて、明細項目が行番1以降にずらずら並んでいる。1伝票処理するのに馬鹿でかいレコードを複数処理しなければならない上に、ストアドプロシージャで簡単には処理できないデータ形式だったんで、大した処理ではないのにステップ数ばかりが増える。その上開発言語がVB2だったから地獄だった。
Re: (スコア:0)
> 行番0がヘッダレコードになっていて
EXCELシート?
Re:1テーブルに全部格納するのは時として必要 (スコア:0)
もちろん、そのシステムにはEXCELシート出力機能がありましたよ。ACCESS版も作ったしVB4,VB5,VB6まで順調にアップグレードしていきました。メモリイーターで困ったシステムでしたよ。DBとランダムアクセスファイルとの違いが分かっていない人が設計すると、ミドルウェアでの扱いに困るDBを平気で設計するのは困ったものです。かたくなにそっちの方が高速だって信じてましたからね。趣味で、まともなDB設計に変更して、C#で1000分の1のステップ数でより高速な互換システム作って、デモを経営陣に見せたら、やっとその担当は首になりましたけど、迷惑な話です。