タグ

developmentとdbに関するktakeda47のブックマーク (8)

  • ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城

    目次・記事一覧(1) レトロゲーム(185) 日記(767) 雑文(511) 書籍・漫画関連(55) 子育て・子どもたち観察(115) ゲームブック(12) フォルクローレ・ケーナ・演奏関連(86) FF14(40) レトロでもないゲーム(334) 始めたばっか(13) アナログゲームいろいろ(37) 人狼(48) ネットの話やブログ論(61) 三国志大戦(20) 無謀的世評(52) ゴーストライター(16) 大航海時代ONLINE(38) FF3(6) Civ4(18)

    ktakeda47
    ktakeda47 2016/05/30
    😂 "・kill -9 を流してもプロセスが落ちない。・仕方ないのでサーバをリブートしようとしてもなかなか落ちてくれないので、どうしようもなくなって電源を落としたらDBが立ち上がらなくなった。地獄絵図である。"
  • イミュータブルデータモデル(入門編)

    [B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya ShinoharaInsight Technology, Inc.

    イミュータブルデータモデル(入門編)
  • DDLレベルの外部キー制約は不要 - 設計者の発言

    テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注

    DDLレベルの外部キー制約は不要 - 設計者の発言
    ktakeda47
    ktakeda47 2013/02/23
    "ようするにDDLレベルの外部キー制約機構は、現実の業務要件を前にしてはイライラさせられるほどに単純で中途半端である。"
  • The SQL Injection Knowledge Base

    Examples: SELECT * FROM Articles WHERE id = '1'''; SELECT 1 FROM dual WHERE 1 = '1'''''''''''''UNION SELECT '2'; Notes: You can use as many apostrophes and quotations as you want as long as they pair up. It is also possible to continue the statement after the chain of quotes. Quotes escape quotes.

    ktakeda47
    ktakeda47 2012/07/07
    "SQL Injection Knowledge Base"
  • 明暗くっきり、オライリーと技術評論社

    オライリーの値段は高いが、質も高い。 自分の専門分野のオライリーは必ず一冊は持っているのが当たり前だった。「サイ」とかにニックネームが付けられてそれで通用するぐらいに、とにかくオライリーのはwebエンジニアにとって特別なであった。そして時代は変わる。 オライリー自体は変わっていないが、時代が変わってしまった。 日語で出版されるオライリーの価値がゆっくりと毀損する間に、技術評論社の書籍の評価はうなぎ上りだ。 うん、ここ最近ではHadoopは秀逸だった。トレンド技術を捉えてうえで数年は価値が落ちない網羅っぷり。 まだ枯れきっていない分野で日語オライリーが存在感を示した最後の例になるかもしれない。 乱立するKVS分野において日語オライリーは無力極まりなしで目も当てられない。 cassandraがようやく出たがversion0.8だ。外人さんが書いた原を数ヶ月から一年か

    明暗くっきり、オライリーと技術評論社
    ktakeda47
    ktakeda47 2011/12/31
    技評の本ってそんなに良いの? "翻訳という形態の技術書の価値が無くなろうとしている。オライリーとて例外ではない。オラの功績はすさまじいものがあるし、足を向けて眠れないぐらいなのだが、・・・日本語の本は日
  • 『アメブロで行ったチューニングの紹介』

    はじめまして。ブログを担当しているNと申します。 ブログ絡みの技術ネタをと依頼をされましたが、 ブログは枯れた技術を多く使っていて目新しいことはあまりないので、 以前行ったチューニング内容について紹介したいと思います。 2008年にブログの記事データについて行ったDB+アプリでのチューニングです。 ブログの記事データはMySQLのMaster-Slave構成で保持していて、 Slaveサーバーをスケールアウトしてブログの閲覧のリクエストを処理しています。 SlaveのMySQLのバージョンは4.1でEngineはMyISAMです。 記事テーブルには以下のようなデータを保持しています。 記事ID,ブログID,記事タイトル,日付,テーマ,公開区分,ステータス,・・・ チューニング前の記事テーブルには以下のようなINDEXを張っていました。Key_name Seq_in_index Collat

    『アメブロで行ったチューニングの紹介』
    ktakeda47
    ktakeda47 2011/07/10
    [for:@twitter]"この変更により同じデータを取得するのに、SQLの発行回数が1回だったものが、1+N回になりました。その結果、AP-DB間のトラフィックは増えたのですが・・・DBのレスポンスが向上したことによって、APサーバーに
  • ソーシャルゲームのためのデータベース設計

    ・データベース的な観点でのソーシャルゲームの特徴 ・データモデル ・ソーシャルゲームに従来型RDBMSを使うべきか、�流行りのNoSQLで行くべきか ・負荷対策 (アーキテクチャ面) ・負荷対策 (ツール面) ・インフラエンジニアのキャリアについて

    ソーシャルゲームのためのデータベース設計
    ktakeda47
    ktakeda47 2011/01/16
    [for:@twitter]"・・・ソーシャルゲームのためのデータベース設計・・・"
  • NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog

    APサーバ層やWebフレームワークの進化によって、Webアプリケーションの開発は昔よりも大分楽になりました。 また、それらのコアとなる部分がオープンソースであるこでお、この恩恵を広く世の中の開発者が受けれるようになりました。 というわけで、最近ではRDBMSを中心とした永続化層のミドルウェアを見直して、よりスケーラブルなアプリケーションを 作れないかという動きが活発化しつつあります。その中心的なものになりうるのが、*NOSQLムーブメント*です。 NOSQLとは、字面のとおり*No SQL*ではないです。Not Only SQLというのが正しい理解で、つまりはRDBMSを効果的に使うには RDBMSが向いている領域に専念させ、RDBMSが向いていない領域では別のプロダクトを使いましょう、ということです。 じゃあどんなプロダクトがあるの?というと、 Google BigTable Amazo

    NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog
    ktakeda47
    ktakeda47 2009/11/10
    「・・・NOSQL指向なミドルウェアとそれによる開発者のパラダイムの変化という動き・・・」本当に来るか注視。
  • 1