タグ

あとで読むとDatabaseに関するmasa8aurumのブックマーク (29)

  • エンジニアのための「Notion」入門

    株式会社SODAの社内勉強会で使用した資料です こちらは株式会社SODAのエンジニア社内勉強会にて @decoch が発表したときの資料です。 株式会社SODAについては以下リンクなどをご覧ください。 これはなに? いま流行りの Notion を使っている方は多いと思うのですが、いまいち使いこなせていない、メモ帳としては使っているけどデータベースってなに? というエンジニアの方向けに Notion の使い方を書いた入門記事です。 Notion とは notion.so からお借りしました ドキュメントやテーブルだけでなく望み通りに機能するようにカスタマイズできるワークスペースです。 基的な使い方 新しくページを作りメモをとったりチェックボックスでタスクを管理したり、Markdown のように使うことができます。 / と打つことでサジェストされ /page と入力し決定をすると新しいページ

    エンジニアのための「Notion」入門
  • どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論

    恥の多い生涯を送って来ました。 システムを開発していると、当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。(まじで意味不明) いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日語でおk。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。(そのうち消したい) システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま

    どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
  • なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか? ~ UNIX/POSIXコマンドの欠点をSQLで解決する

    なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか? ~ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人!? SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える(やらなければいけない)のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル

    なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか? ~ UNIX/POSIXコマンドの欠点をSQLで解決する
  • Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション - Flatt Security Blog

    記事は筆者styprが英語で執筆した記事を株式会社Flatt Security社内で日語に翻訳したものになります。 TL;DR Node.jsのエコシステムで最も人気のあるMySQLパッケージの一つである mysqljs/mysql (https://github.com/mysqljs/mysql)において、クエリのエスケープ関数の予期せぬ動作がSQLインジェクションを引き起こす可能性があることが判明しました。 通常、クエリのエスケープ関数やプレースホルダはSQLインジェクションを防ぐことが知られています。しかし、mysqljs/mysql は、値の種類によってエスケープ方法が異なることが知られており、攻撃者が異なる値の種類でパラメータを渡すと、最終的に予期せぬ動作を引き起こす可能性があります。予期せぬ動作とは、バグのような動作やSQLインジェクションなどです。 ほぼすべてのオンラ

    Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション - Flatt Security Blog
  • Isolation (database systems) - Wikipedia

    This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Isolation" database systems – news · newspapers · books · scholar · JSTOR (January 2009) (Learn how and when to remove this message) In database systems, isolation is one of the ACID (Atomicity, Consiste

    masa8aurum
    masa8aurum 2022/01/31
    トランザクション分離レベル (isolation level) について実例つきで説明している。わかりやすい。
  • タグ機能を実現するための便利なデータベース設計を3つ紹介 | colori

    AND検索 「CSS+HTML+JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LIKE "%HTML%" AND tags LIKE "%JavaScript%" OR検索 「CSS|HTML|JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" OR tags LIKE "%HTML%" OR tags LIKE "%JavaScript%" 引き算検索 「CSS+HTML-JavaScript」で検索する場合は以下のようにします。 SELECT * FROM `delicious` WHERE tags LIKE "%CSS%" AND tags LI

  • ORM は百害あって一利なしは本当か

  • TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話

    こんにちは。DevOps芸人と化して久しいAndyです。 2020年の秋にTypeScript 4.1へTemplate Literal Typesが導入され、そのインパクトに俄かに一部の界隈がザワついたのは記憶に新しいかと思います。 今回は型プログラミングの可能性を大いに押し広げたTemplate Literal Typesを用いてSQL文を型レベルで解析し、その実行結果を型情報として導出するためのsqlptureというライブラリを作ったので紹介します。 Embedded content: https://github.com/andoshin11/sqlpture SQLの実行/検証対象はPostgreSQL v13です。 tl;dr SQL文を型レベルで解析・評価して返り値型を取得できるmini interpreterを作ったよ 型レベルのSQL validatorも作ってるよ 実際

    TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話
  • ScalaDB用ライブラリ、Slickを使い倒すハンズオン - Qiita

    概要 ハンズオンのレポジトリはこちら RubyのActive RecordやPHP(Laravel)のEloquent、PythonSQLArchemyみたいなORMを使うのに慣れている人は結構多いと思われる。 そういう人がScalaでアプリケーションを作ろうとしたときに一番戸惑うのがこのDB周りなんじゃないかと思う。 Java系ライブラリが強いからか、そもそも思想が違うからかORMっぽいDBライブラリがない。それも慣れれば気にならなくなるのだが、最初はそもそもScala自体に慣れていなかったりPlayフレームワークに慣れていなかったりするわけで、追い討ちをかけるように慣れないORMが襲ってくると結構心折れる。 しかも特に今回紹介するSlickとか典型的な使い方は普通に書いてあるしそこまで違和感ないので最初そこまで警戒しないのだが、少しちゃんとしたアプリ作ろうとした瞬間にORMではないと

    ScalaDB用ライブラリ、Slickを使い倒すハンズオン - Qiita
    masa8aurum
    masa8aurum 2020/09/27
    正確には ORM ではなく FRM
  • 本当にあったやらかしDB設計シリーズ一覧 - Qiita

    当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 当にあったやらかしDB設計①【R無しRDB当にあったやらかしDB設計②【囚人番号テーブル】 当にあったやらかしDB設計③【ロジカルクエリー】 当にあったやらかしDB設計④【テストチューニング】 当にあったやらかしDB設計⑤【第三正規化病】 当にあったやらかしDB設計⑥【見えない削除フラグ】 当にあったやらかしDB設計⑦【ステートフルDB当にあったやらかしDB設計⑧【ファンクションDB当にあったやらかしDB設計⑨【文字列日付】

    本当にあったやらかしDB設計シリーズ一覧 - Qiita
  • MySQL入門 レプリケーション編 - Qiita

    #経緯 とある勉強会の内容の復習&整理 #タイトル インストール・アーキテクチャ基礎編 レプリケーション編 ←今回はこちら バックアップ編 チューニング基礎編 #レプリケーション編 アジェンダ レプリケーションとは レプリケーションの仕組み レプリケーションの種類 レプリケーションの設定方法 バイナリログの管理方法 その他の考慮事項 参考情報 #1. レプリケーションとは ##1.1. 基礎知識 データの複製(レプリカ)を別のサーバにモテる機能 MySQLの標準機能で、多数のWebサイト等で利用されている - シンプルな設定で利用可能 - マスター → スレーブ構成 ##1.2. マスタースレーブ構成 サーバはマスター、スレーブまたは両方になれる マスターサーバ - データを変更 - 変更内容をスレーブに転送 - マスターは複数のスレーブを持てる スレーブサーバ - マスターでの変更内容を

    MySQL入門 レプリケーション編 - Qiita
  • DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える!

    DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか? 曽根壮大(soudai)さんによる寄稿です。 こんにちは。そーだい(@soudai1025)です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ

    DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える!
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
  • doobie

  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
  • ORM anti-pattern series

    We as developers tend to apply the same techniques to solve every problem thrown at us. We learn a new design pattern and all of a sudden that pattern is all over our codebase. We find a new way of writing code and we apply it wherever we can because we are very excited about it or because it feels like it could simplify our solution. In the past few years, particularly in .Net space, there has be

  • SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? : i am BEST

    2014年09月03日02:46 カテゴリSQLデータベース SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? 最近のたいていのデータベース製品では、ユーザー定義関数(UDF)という機能が使えるようになっています。Oracle では”ストアド・ファンクション”と呼ばれているものですね。 よく”処理の再利用”とか”処理の部品化”といった用途に使われていますが、パフォーマンスの問題が起こってしまうケースがままあるんですね。 ”集合”を原理とするリレーショナル・データベースの SQL 処理に対して”手続き指向”の発想で立ち向かってしまい、いろんな問題を起こしてしまうことがよくあります。これもそうした例のひとつと言っていいでしょう。 では、”集合指向”での再利用・部品化とはどのように行なうものなのでしょうか?? その答えは、「ビューの利用」なんです。 ユーザー定義関

    SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? : i am BEST
    masa8aurum
    masa8aurum 2018/01/31
    SQL での”再利用””部品化”
  • SQLの部品化について

    非実在naka aki @naka_aki_spl 再掲。SQLは、「完結したクエリ(つまりビュー)」だけじゃ部品化の粒度として大きすぎる。条件とかもを部品(名前付き部品も含む)化したい。個人的に今一番気がかりなのは「結合条件」の「部品」化。 2014-01-30 20:45:44 非実在naka aki @naka_aki_spl ただ、部品化といっても、特に結合条件なんてものは「任意のテーブル/サブクエリ」と好き放題に組み合わせれるハズが無い。使える組み合わせは強く拘束されるはず。、、、これって「型」じゃないのか? 2014-01-30 20:48:58 非実在naka aki @naka_aki_spl ある検索条件(ANDとかで複数合体するのも当然アリ)が「どのテーブル(やクエリ)を指すことができるか」は、「型」だよな。a.b=c.dなんてな条件は、テーブル粒度でいえば「aからcを

    SQLの部品化について
    masa8aurum
    masa8aurum 2018/01/31
    考える参考に。
  • ORMは不快なアンチパターン | To Be Decided

    このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM

  • SQLトランザクション分離 実践ガイド | POSTD

    (注:2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注:2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、来、理解しておくべき基的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ

    SQLトランザクション分離 実践ガイド | POSTD