SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
19歳・東工大2年生が社長。音声合成界に衝撃を与えたCoeFont STUDIOが目指すこれからの世界｜DTMステーション
4月23日、彗星のように現れたネット上のサービス、CoeFont STUDIO（コエ・フォント・スタジオ）は、誰でも無料で使える音声合成サービスということで、瞬く間に広がり、2日で累計ユーザー数が6万人を突破。すでに20万人を超えるところまで来ているようです。日本語でテキストを入力すれば、非常に滑らかな声でしゃべってくれ、その音声をユーザーは商用を含めて自由に利用できるという画期的ともいえるサービスとなっているのです。 このサービスを立ち上げたのは、なんと東京工業大学2年生、19歳の早川尚吾さん。株式会社Yellstonを立ち上げ、その新サービスとして、CoeFont STUDIOをスタートさせたのです。もちろん株式会社ですから、今後ビジネス展開をしていくことを目論んでいるわけですが、それはCoeFont STUDIOの延長線上にあるもので、世の中を大きく変えていく可能性もありそうです。先
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
