MySQLで6桁までの小数点を丸めずに扱うならDouble型かDecimal型を使うべき理由 - Qiita
float型は小数部を含んで6桁までであれば、入力した値そのままに保存出来ます。 簡単に用途をまとめると、こんな感じでしょうか。 小数点以下桁数を揃えて正確に扱うならば、demical型またはdouble型を使う （例:緯度経度情報） 小数部を含んで6桁まで入力された通りに保存する用途であれば、float型を使う そのまま保存したい場合には、varchar型を使う double型とdemical型との違いは次のページがとても詳しいです。 緯度経度情報などdemicalの方が望ましいのですが、double型の方がパフォーマンスは良いです。 Decimal’s declaration and functioning is similar to Double. But there is one big difference between floating point values and de
他システムとのデータベース連携について - Qiita
システムエンジニア Advent Calendar 2015 - Qiita 20日目の記事です。 システム開発をしていると、他システムのマスタやトランザクションデータが必要となる場合がよくありますね。 システム間のデータ連携としては、 リソース共有（データベース共有、ディスク共有） アプリケーション連携（RPC、Web API、MOM1） ファイル連携(CSV連携、etc) などの方法がありますが、ここではデータベース共有を実現するためのデータベース連携方式について考えてみたいと思います。 データベース連携方式について 既存システムがレガシーであったり、違うベンダーが構築したサーバーであるなどの理由で、新機能や拡張機能を別のサーバー上で新システムとして構築する場合があります。もちろん、データベースも新たに用意する場合が多いのですが、その場合は既存システムには極力修正をいれない方針でデータ
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
Rails だって硬いデータベース設計をしたい！そんなあなたに贈る Tips 4 選 - peroli Developer's Blog
2016 - 09 - 09 Rails だって硬いデータベース設計をしたい！そんなあなたに贈る Tips 4 選 list Tweet こんにちは、ペロリのサーバサイドエンジニアの @a_suenami です。 今回は Ruby on Rails アプリケーションにおけるデータベース設計についてちょっとご紹介したいと思います。 データベース設計してますか？ みなさん、データベース（以下、DB）設計していますか？Scaffold したときにできた migration ファイルをそのまま使ったりしてませんよね？ Ruby on Rails （以下、 Rails ）は CoC（Convention over Configuration: 設定より規約）を強く提唱している フレームワーク であり、それによって得られる恩恵も大きい反面、かなり強めに設計の自由度を束縛されるという特徴もあります。特に
1日に100万レコード増える場合のテーブル設計
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
T字系ER手法で僕がしていた論理削除（via とりあえず削除フラグ） - ozamasa’s blog
@t_wadaさんのこのスライド SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 from Takuto Wada www.slideshare.net パラパラと眺めていたら「T字系ER手法」ってのが出てきて、久しぶりにいろいろ思い出してしまったので、ちょっと書こうかなと思います。 T字系ER手法は西暦2000年あたりにSIerの一部で流行っていたデータベース設計手法で、原則（なのか？）についてはこのエントリーに書いてもらってあるとおりです。 mike-neck.hatenadiary.com 抜き出すと、 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意味のあるデータだけのエンティティだけですべての業務のデータを構成できる 日付を持つデータはイベント(これもひとつのエンティティ) NULLのデータは絶対に持ってはならない テーブルはでかく作るな、小さ
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
