データベースオブジェクトの命名規約 - QiitaDB設計によく携わっていた頃に多くのプロジェクトで共通で規定されていた規約をまとめてみました。 ここでは オブジェクト として以下のものを対象としています。 （カラムはテーブルの一部ではありますが、別で切りだしています。） テーブル カラム インデックス 制約 1.全般 大文字を利用しない テーブル名、カラム名ともに大文字を利用しない。 （DBにより大文字小文字を区別するもの、しないものなどがあるため小文字で統一を図る） 名前 OK/NG
SQLスタイルガイド · SQL style guide by Simon Holywell
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
「C.J.Dateの データベース実践講義」からいつか役に立ちそうな話をメモ(2) - 極北データモデリング
一応読了。 へぇと思ったところと、その他思いついたことをメモする。 ORDER BYはリレーショナル演算子ではない 理由は、タプルに並び順のあるもの＝リレーションではないものを返すから。 とはいえ、DateはORDER BYを否定しているわけではない。 便利な道具をリレーショナルモデルの上に積み増すことは、まったく問題ないと考えている。 しかし、積み増した道具が土台のリレーショナルモデルを破壊するなら、その導入には絶対反対の立場を取る。 例えば、ORDER BYはあっても構わないが、ビューの定義にORDER BYを含めることには反対する*1。 outer join否定論も同様。outer joinは便利だが、SQLの世界にnullを呼び込んでしまうのでDateは否定している。 第6正規形とnull 第6正規形の定義は以下の通り。 関係変数Rは、自明でない結合従属性を1つも満たさない場合に限
NULL の AND/OR にはめっちゃ気をつけて！ #phpadvent2013 | Prog Blog From 憩い場所
この記事の所要時間： 約 5分16秒 PHP Advent Calendar 2013の11日目です。 昨日の記事は PHP – コードをまとめる技術としてのイテレータとジェネレータ – Qiita [キータ] です。 本日は NULL と TRUE/FALSE の考え方、特に AND/OR をしたときの動きについてお話しします。 概略 NULL を AND/OR したときの挙動は、 SQL と PHP で違います。 SQL は３値論理であるのに対し、 PHP では NULL 型を boolean 型にキャストしているからです。 プログラミング、特に移行開発をするときには、気をつけましょう。 はじめに שלום! מה שלומך?1 ウェブに携わるお仕事をしているプログラマさんは、マルチリンガルな方が多いかと思います。 PHP と SQL を使ってるマルチリンガルプログラマさん
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
sqlのwhere in って、複数条件(カラム)を指定できるんですね - end0tknr's kipple - web写経開発
http://blog.fusic.co.jp/archives/1765 ↑postgresの記事ですが、mysqlでも同様に実行できました。 SELECT * FROM test_table WHERE (col,co2) IN -- 複数のカラムを指定 (SELECT subcol1,subcol2 -- 副問いの戻り値も複数のカラムを指定 FROM subtable WHERE id > 10 ) 知らなかったなんて、お恥ずかしい ※手元にあるmysqlはv.5.1.61ですが、v.4.1から使えるらしい sqlの仕様として、mysqlのdocでは分かりませんでしたが、sql99から利用可らしい http://dev.mysql.com/doc/refman/5.1/ja/comparison-operators.html ↑では、分かりませんでしたが、次のurlよれば、sql99
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/mpyw/items/c64ce7477169a710f755