Pagination with jQuery, MySQL and PHP. PHP&MySQL+jQueryでページ送りを実装するチュートリアルが公開されていました。 画面遷移なしのページ送りを実装する際の参考にできそうです。 関連エントリ ナビゲーションメニューを1歩進んだものに引き上げるjQueryチュートリアル集 PHPとjQueryのAjax連携の学習用チュートリアル jQueryでアコーディオン作成のチュートリアル
Googleに比べるととっても地味なPRしかしていないが、実はFacebookのエンジニアリングも結構すごい。CTOのJeff RothschildがUCSDで講演したビデオが見れるので今日がある方は是非見た方が良いと思います。 ビデオ http://cns.ucsd.edu/lecturearchive09.shtml#Roth http://video-jsoe.ucsd.edu/asx/JeffRothschildFacebook.asx 解説記事 http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has-30000-servers/ ビデオを見たのが昨日なので、全部覚えていませんが、覚えていることだけでメモを書いておきます。全般的に、非常に素直な講演で、自分たちの良いところも悪いところも素直に言っ
SQLのselect文の書き方の覚書です。 なお、本文中の動作確認は「mysql Ver 5.0.67」で行いました。 2009/10/05 13:30 追記 予想外に多くのアクセスとブクマをいただき、正直驚いております。 本文はsqlの内部処理には一切触れておりません。ごく普通のsqlの書き方にのみ触れています。 釣りのつもりはありませんが、釣られたと感じた方にはごめんなさい。 目次 説明に使用するデータ構造?(というかテーブル) 抽出(where句) ソート(order by句) ソートの例(昇順) ソートの例(降順) 結合(join句) 集計(group by句) 関連記事 説明に使用するデータ構造(というかテーブル) select文の使い方を説明するために、以下のようなテーブルを使います。 create table countries ( name nvarchar(30), cu
なんともSQLの最適化って奥が深いなぁ。 いろいろ勉強&テストしたのでメモメモ。 (ギークな人にはあたりまえのことかもしれないけど…笑) PRIMARY KEYは最優先して使われる。 id > 0 などがWhere句に含まれる場合は、複合インデックスの対象から無視される。 たとえば複合インデックスが(name,age)のとき、 SELECT * FROM hoge WHERE name = "みこ" AND age = 19 AND id > 0 idが含まれて居ないのに、これでも複合インデックスが使われる。 調べてみると、要するに関数に関しては複合インデックスは使われないらしい。 > 、 < 、!= なんかも無理みたい。そういう場合はINで展開すべし、らしい。
MySQL4.0(古い!)の複合インデックスに悩まされたので、まとめておく。 複合インデックスは順番が大事! WHERE句の順番に、しかも使うものは全部インデックス張ろう インデックスが(hoge,moe,miko) のとき、hoge=? AND moe=?では使われるけど、miko=? では使われない。 ORDER BY 句に使うものも全部張る PRIMARY KEY が含まれる場合は一意にレコードが特定されるので、全ての複合インデックスは使用されない。(使用しても無駄) ゆえに、id系を含めて複合インデックスを張る意味は無い JOINする場合は別々に とにかく、まずはEXPLAINでおk 解析には本家リファレンスを参照 めんどくせー! どうやらMySQL5系だとオプティマイザが幾分優秀らしい。 続きは明日やろう…。がんばろう!!
先日の MySQL Conference 2009 のプレゼン資料は公開されていますが、その中で MySQL V3 Google Patch のパフォーマンスに関するスライドが公開されていたので、さっそくチェックしてみました。 該当する講演は、「This is Not a Web App: The Evolution of a MySQL Deployment at Google」にあたると思われます。 MySQL colud performance というスライドから。 ベンチマークツール: iibench、sysbench、wisconsin InnoDB を高速にするには、tcmallock とリンクする、XFS ( noatime,nodiratime,nobarrier オプションを指定するのがいいらしい)を使う、マルチコアサーバ用の mutex contention を減らす、
WordPress 向けのカスタマイズ本「WordPressで学ぶPHPとMySQL」を紹介します。 この書籍は、著書の藤本壱さんが配布する PDF 本の(多分)第2弾です。ちなみに第1弾は「Movable Type Developer's Guide Volume 1」です。 書籍の前半は、PHPの基礎とWordPressを使った制御文の説明など。後半はGETデータ、POSTデータの受け渡し方、Cookie の利用、関数や正規表現の利用方法、さらにオブジェクト指向プログラミングやデータベースへの直接アクセスや、wpdbオブジェクトを利用したデータの取得方法、カスタムフィールドを使った検索など、サイト制作に役立つと思われる実用的なノウハウが満載です。 また、書籍では開発ツールのEclipse PDT(PHP向けの開発環境)を必要に応じて用いており、手順通りに行なえば、作成したソースコードの
Webサイト制作。PHPとかMySQLとかプログラム寄り。symfony、CakePHP。Perlと和解交渉中。 自分は遭遇した事無いけど、今後の参考に。 PHPの内部処理の文字コードがEUCベースな為、UTF-8で作っていくとフォーム値が文字化けしてしまう事があるらしい。 結構多いトラブルの模様。 解決策としては、内部処理の文字コードをUTF-8に変更してから受け取る様にすると良い。 自分の経験で悩まされたのは、DBの文字化け。 DBを一から構築する場合は最初からUTF-8で作っていけば良いけど、サーバの移転だったり既存のデータを使ったプログラムを組みときは文字化けが大変。EUC-JPが多い。 その時は以下のコードで文字コードを指定したクエリを発行して乗り越えられた。 <? mb_language("uni"); mb_internal_encoding("utf-8"); /
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い!情報の正確性は自己責任で判断してください。 あるシステムにDB(データベース)を実装しようとする場合、RDBMSにOracleを使うかMySQLにするかPostgreSQLを選択するかってのもあるけど、まず実際どういうDBにするのか設計すると思う。Sig.の場合、設計時のコンセプトは次の2つ。 重複を避ける 求めるデータを「特定できる」ようにする DB設計を厳密に行う手法には「リレーションの正規化」というものがある。これはデータの一貫性を維持し、不整合と冗長性を避け、効率的なアクセスを可能にするための設計手法。単に正規化ともいう。正規化には幾つか段階があるけど、実務の際には第三正規形までに止めて、それで十分とす
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
現在の Unix システムでの最大時刻は、協定世界時の2038年1月19日午前3時14分7秒です。 http://www.ruby-lang.org/ja/man/?cmd=view;name=Time Timeは2038/1/19以降がエラーになる。 >> Time.gm(2038,1,19).strftime("%Y-%m-%d %a") => "2038-01-19 Tue" >> Time.gm(2038,1,20).strftime("%Y-%m-%d %a") ArgumentError: time out of range from (irb):7:in `gm' from (irb):7 from :0DateTimeはもっとずっと先まで大丈夫。 >> require 'date' => true >> DateTime.civil(2038,1,19).strftime(
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
しばらくブログを更新していなかったのですがそろそろ再開しようと思います。 ここ半年くらいTritonnに動きがなかったと思うのですが、この間新しいストレージエンジンの開発に着手していました。Sennaの後継プロダクトとしてgroongaがリリースされましたが、このgroongaをMySQLのストレージエンジンにするというものです。 新しいストレージエンジンはもうしばらくしたらテストリリースする予定です。 従来のMySQL 5.0向けのTritonn(MyISAM+Senna)は大きなトラブル(落ちるバグなど)も無かったのでしばらくアップデートしていませんでしたが、こちらも来月あたりにアップデート版をリリースしようと思っています。 このアップデート版ではMySQL 5.0の最新版へ追随すると共に、今までTritonnでは実装していなかった「ORDER BYしなくてもscore順でソートしてお
Excelで作ったデータをデータベースに取り込む、なんて要件はよくある。面倒だがExcelデータをCSVに変換して、1番目のカラムが名称、2番目のカラムが価格…なんて定義したりした経験はないだろうか。 ビジュアル的にデータのインポートを定義する それがさらに関連しているテーブルに渡って処理しないといけないなんてなったらパニックだ。そこで使ってみたいのがdbTubeだ。 今回紹介するフリーウェアはdbTube、ビジュアル的にモデル定義ができるインポートプログラムだ。ソースコードは公開されているがライセンスは明記されていなかったのでご注意いただきたい。 dbTubeの良さは何と言ってもビジュアル的にデータの定義ができることだ。Open-jACOB Draw2Dを使って元になるExcelデータとテーブルのマッピングがドラッグアンドドロップでできる。さらにExcelデータは何行目から読み出すかと言
先週、概要を紹介させていただいた Pacific について。まだ API をフリーズしていないつもりなのですが、だいぶ整ってきた気がするので、ざっくりまとめておきたいと思います。 インストール手順 Thrift をインストール注1 Pacific の svn レポジトリからチェックアウト Perl ドライバを make (cd driver-perl && perl Makefile.PL && make all test install) リゾルバを make (cd resolver && make) テーブルのセットアップ手順 テーブルのセットアップは、pschema コマンドを使って行います。 # リゾルバの裏側の MySQL は 127.0.0.1:33060 で動作 # # プライマリテーブル「user」を作成 # ・ 分散キーの名前は「username」 # (
設計 MySQL Workbench は、 DBA、開発者、データアーキテクトがデータベースの設計、作成、管理をビジュアルに行うことができるツールです。データモデラーが複雑な ER モデルの作成、フォワードおよびリバースエンジニアリング作業を行うために必要な機能を含み、難しい変更管理や、通常かなりの時間と労力を必要とするドキュメンテーション作業の為の重要な機能なども含まれています。 詳しくはこちら » 開発 MySQL Workbench は、SQL クエリーの作成、実行、最適化をビジュアルに行えるツールを備えています。SQL エディタは、シンタックスのカラーハイライト、自動補完、SQL ステートメントの再利用、SQL の実行履歴情報を提供します。Database Connections Panel によって MySQL Fabric を含む一般的なデータベース接続の管理が容易になります。
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く