Upgrade for image upload, smarter AI, and more Pro Search.

Upgrade for image upload, smarter AI, and more Pro Search.
話したネタ 論理削除とはそもそも何か? 物理削除とは? なぜ、論理削除が生まれてくるのか? SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か? なぜ、論理削除はアンチパターンとして捉えられるのか? 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か? テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか? 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか? ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft
技術書典7の新刊「わかりみSQL」です。 500ページを超える大作ですが、SQL初心者が挫折するポイントを丁寧に説明しているのでスラスラ読めます。 読んでも理解できない50ページより、読んで理解できる500ページを! 試し読みはこちら。読んだうえで購入するようお願いします。 https://kauplan.org/books/wakarimisql/ 推薦のことば> 今回レビューさせて頂いた「わかりみSQL」は、本当に過程を丁寧に説明していて、これまで読んできた技術書で一番わかりやすかった > 特に、考え方や図を使った過程の説明などは本当にすごくわかりやすくて、これ読めば誰でもSQLわかるんじゃない?と思ったくらい > 自分の本よりも勧めたいくらい良かった https://twitter.com/gorilla0513/status/1173388709112057857 > 以前SQLに
Amazon Web Services(以下AWS)は、SQL互換の新しい問い合わせ言語およびそのリファレンス実装である「PartiQL」をオープンソースとして公開したことを発表しました。 PartiQLはSQL互換の構文に最小限の拡張を施すことで、リレーショナル形式のデータベースだけでなく、KVSやJSONなどを含むNoSQLデータベースやCSVファイルなど、さまざまなデータソースに対して横断的に検索できる問い合わせ言語およびそのリファレンス実装です。 下記はPartiQLを発表したブログからの引用です。 Today we are happy to announce PartiQL, a SQL-compatible query language that makes it easy to efficiently query data, regardless of where or in
なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ
以前のエントリで「次回は履歴を保存する方法について解説します」と書いたのですが、その前に気になるテーマを見つけたので、今回は予定を変更してそちらの解説を行いたいと思います。 その気になるテーマというのは、表題の通り、関係データベース (RDB) における配列の取り扱いについて。 そもそも、リレーションモデルでは、原則的に単一のカラムはスカラを表すため、これを用いてベクタである配列を直接表現することはできません。 (参考: リレーションの正規化#第一正規形 - Wikipedia) しかしながら、実際には配列というデータ構造を用いずにシステムを設計・開発することは現実的に不可能です。 結論から言えば、関係データベース上で配列を表現するためのごく簡単なテクニック (というほど大げさなものでもない) があるのですが、少なくとも私が観察した範囲では、その手法にはこれと言った名前が付けられておらず、
この記事は C# Advent Calendar 2014 の 6 日目の記事です。LINQPad の基礎的な機能について解説します。 LINQPad をご存知の方はもしかしたら多いのかもしれず、あるいは少ないのかもしれませんが、このツール、LINQPad という名前ではありますが LINQ とはあまり関係ありません。名前で結構損をしてるのではないかと常々思ってしまうので、ちょっと残念な感じではあります。 もちろん LINQ のお勉強にも便利なのは間違いないのですが、お手軽な C# / F# / VB コードの実行環境として、また、.NET オブジェクトを見やすく出力することのできるツールとして、十分に便利なツールです。Visual Studio の C# Interactive もしばらく出てこなさそうですし、ちょっとしたコード パッドとしてだけでも十分有用ではないかと思います。 ですが
LINQPad is not just for LINQ queries, but any C#/F#/VB expression, statement block or program. Put an end to those hundreds of Visual Studio Console projects cluttering your source folder and join the revolution of LINQPad scripters and incremental developers. Reference your own assemblies and NuGet packages. Prototype your ideas in LINQPad and then paste working code into Visual Studio. Or call y
Apache Spark 2.0正式版がリリース。ANSI SQL標準サポート、10倍以上の高速化など 分散処理フレームワークの「Apache Spark 2.0」正式版のリリースが、開発元のDatabricksから発表されました。これまでApache Sparkはバージョン1.x(直前の最新版は1.6)でしたので、メジャーバージョンアップとなります。 Spark 2.0で最大の新機能は、新しいSQLパーサーを採用したことによるANSI SQL(SQL 2003)への対応です。ビッグデータのベンチマークの1つであるTPC-DSの99種類のクエリがそのまま実行可能と説明されており、プログラマが慣れ親しんだ一般的なSQL文はすべて実行可能になります。 また、DataFrameとDatasetは統合されたAPIとなりました。 こうしたAPIの変更や改善が行われた一方で、Spark 2.0ではパフ
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか?」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職(・転属)する (売掛金の回収を諦めて)売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
好きな IPA は志賀高原ビールの @soh335 です。 早くビール飲みたいのですが書かないと怒られるので今日は、隣の発明家が作った GitDDL というモジュールについて説明しますね。 (隣の発明家に任せると「GitDDLまじイノベーティブ(完)」としか説明してくれないので) なにするものなの 名前を見て通り、Git で database の schema 管理をするものです。それ以前は、DBIx::Class::Schema::Versioned とかを使っていたようです。 仕組み まず、Git で管理されている schema ファイルを指し示すコミットのハッシュを database 上で管理します。 schema に変更があった場合、このコミットのハッシュが databse 上のものとで差異が生まれます。よって database 上の schema は期待する schema ではな
#5「GitDDLまじイノベーティブ」 tech.kayac.com Advent Calendar 2012 | tech.kayac.com - KAYAC engineers' blog が便利そうだなーと思って。 でもGitと絡めなくても、Webアプリにおいて「現在の環境で使用するデータベース」と「有るべきスキーマの状態を示すDDLファイル」の差分を取って埋めることができればそれだけで十分使える気がする、と思って一つの運用方法を考えてみた。 もちろんGitDDL使っても良いのだけど、SQL::Translatorを使うだけでもある程度は、ということで。 Amon2プロジェクトの例で。 初期設定 $ amon2-setup.pl MyAppとかで雛形プロジェクトを作ると、sqlディレクトリが作られて、そこにDDLを保存する雰囲気になる。そのままsql/mysql.sqlを使っていくこ
■前回までのあらすじ わんくま東京#83でSSISのセッションをやったら、SSISのプロジェクトを1から作る奴はいないと指摘を受けたので調査することにした。でも僕が数年前に見たSSISのチュートリアルには前回の記事の流れだった記憶があるのですよ。 ■後になって知ったこと 聞いた話によるとSQL Serverのデータのエクスポート/インポートはSSISで動くらしい。実際にエクスポート/インポートの手順を踏んでみるとわかる。 データベースを右クリック→「タスク」→「データのインポート」をクリック。 まずは移行元の接続先を設定する。 同様に移行先の接続先を設定する。 データの摘出方法を設定する。加工が一切ないのならば「1つ以上のテーブルまたはビュー・・・」でよいと思うが、「~クエリを記述する」を選択する。 摘出用のクエリをコードする。 変換先のテーブルを対象のテーブルにする。 続いて「マッピング
先週末にわんくま同盟東京勉強会#83で喋ってきたはずなのだが、どういうわけかデモ中心セッションではなく雑談中心セッションとなり、肝心のデモは3分クッキングになってしまったので、こちらで掲載することに。 目次 ■データ移行の案件とは ■SSISとは ■SSISを触ってみる ■まとめ ■セッション後 ■データ移行の案件とは 旧システムから新システムに切り替える際に発生するデータの引っ越し作業。新システムのテーブル仕様に合わせて旧システムのデータを摘出・加工を施してデータの移行を行う。システムではなく手動で変更して整合性の取れなくなったデータ、以前の移行からほったらかされているデータも(通称ゴミデータとも言う)このタイミングで補正をかけて移行することがある。 案件を実施するタイミングは大きく分けて2通りあり、「タスクが放置されていて新システム完成間際に慌てて始まる」、「新システムの製造と並行で移
ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか? SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
ひしだまHPの更新履歴。 主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。 Hadoop Conference Japan 2014(HCJ)で自分が聞いた講演の個々の感想はブログに書きましたが、それとは別に全体として思ったことがあるので書いておきたいと思います。 簡単に言うと、「最近のHadoopの利用事例はどうなっているんだろう?」 もう少しくだけて言うと「皆はHadoopをどう使おうとしているんだろう?」ということです。 今回のHCJの各講演の題目を見る限り、YARN・SQL・Sparkの話題が多かったと思う。 Hadoopの主要な仕組み自体は今後YARNになっていく感じなので、YARNの話が出てくるのは分かる。 しかし、SQL関連がこんなに活発なのが個人的には驚き。 SQLは対話型ツールで使うのにはとても向いていると思う。 一度の操作では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く