#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
DBIのconnect_cachedのいろいろ - $shibayu36->blog;
最近DBへの接続をリクエスト単位ではなくリクエストを処理するプロセス単位(Starmanのworkerプロセス単位)でキャッシュしたいということがあって、DBIのconnect_cachedを使うことになった。Scope::Container::DBIでももしかしたら出来るのかもしれないけど、とりあえずconnect_cachedで実装した。そこでいろいろはまったのでメモ。 connect_cachedについて perldocに connect_cached is like "connect", except that the database handle returned is also stored in a hash associated with the given parameters. If another call is made to connect_cached wit
MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと
— そーだい＠初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言） まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
とりあえず何でも書く
前回に引き続きデータベースの命名規則についてまとめる。 データベースの話の前に、いろいろ調べると命名規則に関して専門用語（？）があったので簡単に触れる。 ■snake case スネークケース 文章をアンダースコアで区切る記載方法 例）hello world → hello_world ■camel case キャメルケース 単語の先頭の文字を大文字にして区切る記載方法 例）hello world → helloWorld (camel notation キャメルノーテーション) 例）hello world → HelloWorld (upper camel アッパーキャメル) ※ちなみにキャメル＝らくだ。文字の並びがでこぼこしてらくだのコブのようだからこう呼ばれるらしい。 上記はこのあと出てくる用語。 ではデータベースの命名規則に関して、下記の記事をみつけたのでまとめてみた。 Datab
【データベース設計】 テーブル名、カラム名の名前の付け方（命名規則） at softelメモ
データベース設計のテーブル名、カラム名の物理名について、とても個人的な自分ルールをご紹介。 テーブル名は、 小文字英数字とアンダースコアだけ使う。大文字は避ける。 一般的な英単語、ローマ字（ヘボン式）でつける。多少長くなってもいい。 頭に何かつける（t_***、m_***、c_***など）。 カラム名は、 小文字英数字とアンダースコアだけ使う。大文字は避ける。 一般的な英単語、ローマ字（ヘボン式）でつける。 頭にテーブル名を付ける。ものすごく長くなってもいい。 大文字小文字はDBMS、OS、プログラミング言語によって区別されたりされなかったりするので、無用なトラブルを避けるため。 ヘボン式で統一すれば、ツはtuなのかtsuなのか、シはsiなのかshiなのかで迷わなくなる。 テーブル名に t_***、m_***、c_*** などを付けて、テーブル、マスタ、多対多の関連を表すテーブル、ログ的な
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
