1日に100万レコード増える場合のテーブル設計 | teratail
株価データをmysqlにinsertするシステムを組んでおります。 全銘柄の株価を1分おきに取得します。 銘柄数は3600、株式市場の時間は1日300分 3600×300=1,080,000レコードとなります。 カラムは以下の通りです。 id int(10) AUTO_INCREMENT code smalint(5)//銘柄コード price double//株価 dekidaka int(10)//出来高 created_at date//取得時刻 selectする際の速度を最重視するため、 ストレージエンジンはMyISAMを採用し、ORMは使用しない予定です。 普段テーブル設計をする際はupdated_atカラムを含ませているのですが、 レコード数が膨大になって容量を食う上、updateも行わないため除いています。 ・insertは遅くても問題ない ・updateは基本的に行わない(
MySQLでidだけをSELECTして、カンマ区切りにして出力する - kanonji’s diary
SELECT GROUP_CONCAT(id SEPARATOR ', ') FROM examples; +-------------------------------------------------------------------------------------+ | GROUP_CONCAT( id SEPARATOR ', ') | +-------------------------------------------------------------------------------------+ | 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146 | +--------------------------------------------
SQLite用のAdminツール、SQLiteManager | プログラムの種 ブログ
MySQLを使うとき、ブラウザからphpMyAdminで操作すると楽ちんですので、SQLiteを使うときも同様にAdminツールを使いたくなる私です。 SQLiteManagerが、日本語にも対応しているので使いやすいと思います。 UTF-8で使う場合は、日本語設定ファイルである lang/japanese.inc.php を開いて、10行目あたりにある$charsetをutf-8に、$langSuffixをja-utf-8に変更します。 そしてjapanese.inc.phpの文字コードをUTF-8に変換して保存します。 Windows版で使う場合、テーブルが読めないバグのがあります。include フォルダ内の add_database.php の17行目あたり [php] if(isset($_POST[‘dbpath’])) $dbFilename = stripslashes($
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これからMySQLをイチから学ぶ人に捧げたい23個のコマンドリスト
