アカウント名:
パスワード:
だって、和書に Ruby はつきものですし。
まあ、お約束はこのくらいにして、70万件なんてさほど大きいデータベースとは思えませんが、それでも強調しているのは、RoR 標準の AcriveRecord がチューニングなんて少しも考えていないSQL をはくからかもしれません。
プロトタイプ開発にはいいですが、本番で使う時には、すこし手をいれた方がよいでしょうし、今回のはそれをちゃんとやってあるということなのでしょうかね。
そういえば少々気になるのがRails(AR)のスキーマ構造の縛り。
PKは「ID」のみだとか、FKは「(別テーブル名)_ID」のみだとか、という縛りに従ったうえで、数十万オーダーを無事捌けているってことだと理解していいんですかね?
テーブルの綺麗さ(ワケワカになりにくさ)という意味ではARなどが採用するあの「ID縛り」は歓迎してるんだけど、性能を両立しないと隣人を説得できないんでさ。
どんなもんですか?>実地投入なさってる諸兄
#気まぐれとしか思えないような"様々な"方法でテーブル間をJOINしやがってる読みづらいスキーマよりは(メンテコストが)マシだろ、と思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
Ruby は図書館システムにぴったり (スコア:1)
だって、和書に Ruby はつきものですし。
まあ、お約束はこのくらいにして、70万件なんてさほど大きい
データベースとは思えませんが、それでも強調しているのは、
RoR 標準の AcriveRecord がチューニングなんて少しも考えていない
SQL をはくからかもしれません。
プロトタイプ開発にはいいですが、本番で使う時には、
すこし手をいれた方がよいでしょうし、今回のは
それをちゃんとやってあるということなのでしょうかね。
Re: (スコア:0)
そういえば少々気になるのがRails(AR)のスキーマ構造の縛り。
PKは「ID」のみだとか、
FKは「(別テーブル名)_ID」のみだとか、
という縛りに従ったうえで、
数十万オーダーを無事捌けているってことだと理解していいんですかね?
テーブルの綺麗さ(ワケワカになりにくさ)という意味ではARなどが採用するあの「ID縛り」は歓迎してるんだけど、
性能を両立しないと隣人を説得できないんでさ。
どんなもんですか?>実地投入なさってる諸兄
#気まぐれとしか思えないような"様々な"方法でテーブル間をJOINしやがってる読みづらいスキーマよりは(メンテコストが)マシだろ、と思う。