タグ

関連タグで絞り込む (45)

タグの絞り込みを解除

designとSQLに関するraimon49のブックマーク (18)

  • なぜSQLiteはバイトコードを使うのか

    以前にデータベースを自作しようとして、SQLiteのアーキテクチャを見てみたらVMだったことに疑問を感じ、それをツイートしたところ作者からリプをもらいました。 作者いわく、次のような背景があったとのことでした。 SQLiteを作った当初はデータベースエンジンのことをよく知らないがコンパイラのことをよく知っていた SQLデータベース・エンジンを書くという問題をコンパイラ構築の問題として扱うのは自然なことだった データベースエンジンのコアの部分をVMにするという発想がまったくなかったので、どんなメリットがあるのか？と気になっていました。 それを作者に聞いたら、詳細な説明ページを作ってくれました。 個人的にVMにしたことで、評価&実行のパフォーマンスは多少良くなると思うが、データベースエンジンのパフォーマンスにそれほど寄与していないんじゃないかな？って思ったりしました。 本記事はそのページについ

    なぜSQLiteはバイトコードを使うのか

  • Goにおける型によってSQLインジェクションを防ぐ方法


    はじめに 2022年のセキュリティ・キャンプ全国大会に講師として参加しました。その際に、Goにおける脆弱性への対策はどうなっているのか調べました。この記事では、github.com/google/go-safeweb/safesqlがどのようにSQLインジェクションを防いでるのかについて解説します。 なお、@rungさんの文書を多いに参考にしております。また、セキュリティ・キャンプで用いた資料はこちらから閲覧できます。 SQLインジェクションとは？ 独立行政法人情報処理推進機構︵IPA︶が公開している安全なウェブサイトの作り方を見ると、SQLインジェクションは以下のように説明されています。 データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基にSQL文︵データベースへの命令文︶を組み立てています。ここで、SQL文の組み立て方法に問題がある場合、攻撃によってデータベ
    Goにおける型によってSQLインジェクションを防ぐ方法

  • 決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ


    エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DBの Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
    決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ

  • Go の sql.DB がコネクションプールを管理する仕組み

    Go の database/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基本的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接

    Go の sql.DB がコネクションプールを管理する仕組み

  • Re: Rails を主戦場としている自分が今後学ぶべき技術について


    この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が RubyonRails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と RubyonRails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
    Re: Rails を主戦場としている自分が今後学ぶべき技術について

  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳


    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作るtableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
    raimon49
    raimon49 2018/05/02
    親となるusersテーブルを削除フラグやトランザクションから守ることを可能とする設計。ユーザーのIDが生きてるか退会済みかは、専用にテーブルを作って管理する。
    リンク

  • RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！


    ﹁ユーザー目線﹂のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、﹁テーブル﹂と﹁SQL﹂の発明です。 RDBでは、すべてのデータを﹁テーブル﹂というただ一つのデータ形式によって表現します。テーブルは、見た目が﹁二次元表﹂に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
    RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
    raimon49
    raimon49 2017/11/28
    ＞Postgresは「Post（後の）」＋「Ingres」から付けられた名称です。 / ポスグレの前身としてIngresというRDBが生まれていた。
    リンク

  • Rebuild: 169: Your Blog Can Be Generated By Neural Networks (omo)

    Hajime Morita さんをゲストに迎えて、達人プログラマーなどについて話しました。 Show Notes Rebuild: Supporter Naoya Ito: "業界の悪習: 新人に10冊も20冊も自分が読んだ本を薦める" 新装版 達人プログラマー 職人から名匠への道 | Amazon 新装版 達人プログラマー 職人から名匠への道 | オーム社 eBook Store The Pragmatic Bookshelf Convolutional neural network Rational Unified Process UML 統一モデリング言語 Plantuml レガシーコード改善ガイド Add Code from a Template | Android Studio Protocol Buffers Amazon Athena Sumo Logic Splunk jq

    Rebuild: 169: Your Blog Can Be Generated By Neural Networks (omo)
    raimon49
    raimon49 2016/12/25
    プレーンテキストの限界と構造化テキスト表現の話、DSL作り出してしまう病。すごく面白い。
    リンク

  • RDBアンチパターン // Speaker Deck

    PHPカンファレンス2016の資料です http://phpcon.php.gr.jp/2016/

    RDBアンチパターン // Speaker Deck
    raimon49
    raimon49 2016/11/03
    ステータスを表すカラムではなくレコードの追加で歴史を作る。
    リンク

  • PHPerに知ってほしいRDBの事 その3

    PHPカンファレンス関西 2016の資料です。 http://conference.kphpug.jp/2016/

    PHPerに知ってほしいRDBの事 その3

  • ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try


    はじめに 先日、社内で﹁良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？﹂という話になりました。 もちろん、﹁本を読んで勉強する﹂っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
    ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
    raimon49
    raimon49 2016/08/09
    COBOLほとんど知らなくてもCOBOL流儀な設計や変数をちょくちょく見かけるのが日本IT業界の闇。
    リンク

  • スマートフォンの連絡帳の話。 - なるようになるかも


    純正の連絡帳で別に満足してるって人もいれば、オリジナルの連絡帳を入れてる人もいますし、そもそも連絡帳に何も登録されてない人もいるでしょう。 それはさておき、iOS や Android のOS標準の連絡帳はユーザー視点で見るか、開発者視点で見るかで貧弱とも言えるし、高性能とも言えて面白いです。 連絡帳の基本思想 iOS / Android に共通して言えることとして、実用的ではないです。グルーピング表示すらできません。 その理由は、OS標準の連絡帳は、端末内の利用出来る情報を活用しつつ、様々なアプリへ連絡帳情報を提供するためのデータベースとなるよう、割り切った実装になっているからです。 連絡帳の元データは、多種多様です。 Android であれば Google アカウント、iOS であれば iCloud アカウントに紐付いていることが多いと思います。 その他にも SIM カードやソーシ
    スマートフォンの連絡帳の話。 - なるようになるかも
    raimon49
    raimon49 2016/06/23
    ロケール依存したソートや電話番号ルックアップ用テーブルの実装について。
    リンク

  • ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita


    コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、︵主に土日に︶サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 ︻ステキポイント︼ ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます︵4歳の息子談︶ 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、﹁どんなところをチェックすればいいのか分か
    ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
    raimon49
    raimon49 2016/04/08
    いずれも妥当だし、こういう風に自分が何に着目してレビューしてるか言語化できるスキルって大事。見習いたい。
    リンク

  • SQLアンチパターン 幻の第26章「とりあえず削除フラグ」

    SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less

    SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
    raimon49
    raimon49 2015/09/01
    is_delete2の登場に戦慄した。フラグよりもxxxx_atで日時やUNIX timeを持つ方がWhyが明確になって一つの解決策たり得る場面はある。
    リンク

  • 分散システム処理モデルに関する動向について（MapReduceからBorgまで）


    詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化︵限定︶されたモデルであったと言えます。 また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。 関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。 純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
    分散システム処理モデルに関する動向について（MapReduceからBorgまで）

  • 書籍出版のお知らせ：理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL


    来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは﹁理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL﹂となっている。単に﹁データベース﹂と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、﹁そもそもRDBの使い方があまり理解されていないのではないか﹂ということだった。名著、SQLアンチパターンでは﹁やってはいけないケース﹂について学ぶことができるが、その反対のテーマ、つまり本来どの
    書籍出版のお知らせ：理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
    raimon49
    raimon49 2015/02/02
    ＞この書籍は残念ながら、初心者向けではない。SQLの基礎やRDBの基本的な使い方といったものは解説していないからである。
    リンク

  • NoSQLデータモデリング技法


    NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文‥NoSQL Data Modeling Techniques « Highly ScalableBlog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
    NoSQLデータモデリング技法

  • 複合主キーを避けるべき理由 - 虎塚


    データベース設計の話をしていて、﹁連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき﹂という意見を聞く機会がありました。 脊髄反射で﹁ないわー﹂と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 ︵2011/07/25 追記︶複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、﹁避けるべき﹂というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
    複合主キーを避けるべき理由 - 虎塚
    raimon49
    raimon49 2011/07/14
    業務要件によりけりだとは思うけど「あまりにも多くの方が、PK制約以外にユニーク制約を付けるということを（DB設計を本業としてる人でさえ）忘れている、あるいはそのような機能が大半のRDBMSにあるのを知らないという
    リンク
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.