Sqlime is an online SQLite playground for debugging and sharing SQL snippets.

爆速のアイコン検索サイトを作ったので、遊んでみてください。 (1) まずは自分が使いやすいアイコン検索サイトを作りたかったので作りました。(2) 様々なアイコンを爆速で横断検索し、サクッとアイコンをコピーできるようにしました。単純ながら意外とその部分が面倒なサイトは多い気がします。(3) また応用とメンテがしやすい実装にして、非常にサポート範囲の広い DB を GitHub Pages 上で構築しました。公開時点では 120+ のアイコンセットと、130,000+ のアイコンをサポートしており、サポート数も観測範囲では No.1 です。 開発動機 アプリ/サイト開発ではまずお世話になるであろうアイコン。私はこれまで Material Icons と Bootstrap Icons ばかり使っていました。これは検索が面倒だったからです。検索が面倒だと知名度の高いものだけに閉じてしまうので、良
WHERE 条件のフィールドを UPDATE するのって,明示的にロックしてなくても安全?全パターン調べてみました!MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも, MVCC アーキテクチャの恩恵で, SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ,排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ,これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で,更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離
公式の説明を引用すると下記のとおりです。(Google 翻訳) 開発者、SQL プログラマー、データベース管理者、アナリスト向けの無料のマルチプラットフォームデータベースツール。 JDBC ドライバーを備えたすべてのデータベースをサポートします(基本的には-ANY データベースを意味します)。 商用バージョンは、MongoDB、Cassandra、Couchbase、Redis、BigTable、DynamoDB などの非 JDBC データソースもサポートしています。商用バージョンでサポートされているすべてのデータベースのリストは、ここにあります。 ・メタデータエディタ、SQL エディタ、リッチデータエディタ、ERD、データのエクスポート/インポート/移行、SQL 実行プランなどの多くの機能を備えています。 ・Eclipse プラットフォームに基づいています。 ・プラグインアーキテクチャを
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく(自分の経験則)、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか?を熟考する必要があります。(例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話) また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
@tkanayama_です。「SQLアンチパターン *1」 という本を読みました。「ポケモンを題材に因果推論を実践してみる」のように、仮想的なストーリ上で実際に使ってみた感を出すことにより、自分の記憶に定着させることを狙います。 前提として、何をアンチパターンとするかは状況(ベンダーフリーである必要があるかどうか、どの程度の頻度で更新されるか・・・など)によって大きく異なるので、下記で紹介するアンチパターンは実は状況によっては問題にならないケースもあるかと思います。この投稿はあくまで「SQLアンチパターン」に忠実に従うことが目的です。 www.oreilly.co.jp 追記 登場人物 ストーリー フシギダネへの対応 ヤミカラスへの対応 ディグダへの対応 誤登録でポケモントレーナーになってしまったユーザーの削除 最後に 謝辞 追記 このブログを公開後、「外部キー制約はレコードロック周りのト
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 Db2 (LUW)U
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド(日本語訳) 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、一休.comスマートフォンホテルページリニューアルをリリースし、パフォーマンスが改善した話を書きます。 概要編はこちらになります。 user-first.ikyu.co.jp JavaScriptパフォーマンス改善編はこちらになります。 user-first.ikyu.co.jp CSS・その他パフォーマンスチューニング編はこちらになります。 user-first.ikyu.co.jp この記事ではスマートフォンホテルページリニューアルで実施したサーバサイドチューニングについて書きます。 ここでお話しする内容 サーバサイドチューニング前後のOverview プロジェクトの大まかなタイムライン ボトルネック洗い出し 対策 SQL改善 不足インデックスの設定 => 600msの改善 複雑なselect文をシン
Looking for an Amazon Redshift client? TeamSQL has retired and is not available for download anymore. You can The world's first and the only query and management tool built for Amazon Redshift. Get DataRow for Amazon Redshift Hello, TeamSQL has been a great platform to experiment with modern UI and powerful features to help you manage your popular databases with collaborative features. Over two ye
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
これまで「SQLアンチパターン」本のまとめを書いてきました。 「SQLアンチパターン」を避けるためのチェックリスト①(DB論理設計編) - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト②(DB物理設計編) - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト③(SQLクエリ設計編) - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト④(アプリケーション設計編) - log4ketancho この記事は、自分用のチェックリストとして、これまでの記事をサマライズしたものになります。本にこのチェックリストが書かれているわけではなく、個人的に解釈したものになりますが、もしよろしければ DB 設計の一助にしていただければ幸いです。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,
こんにちは、データ分析部の石塚です。 Gunosyではエンジニア以外の職種でもSQLを叩いて自らデータを集計・分析するという習慣と全社員が各サービスのログ*1に触ることができる環境があります。 例えば、ユーザー獲得を担っているプロモーションチームはエンジニアが0名のチームなのですが、実際にSQLを叩いています。 それによって、自分たちの獲得したユーザーはどのような行動をしているのかを確認したり、分析することができています。 これはGunosyのみの事例ではなく、AWSのRedshiftやAthena、GCPのBigQueryが台頭してきたおかげで、どの会社も低コストにログをSQLで集計・分析できる基盤が整ってきています。 個人的にはアプリやウェブの業界で働くマーケターにはSQLは必須の知識と言える時代になってきたと感じています。 そこで今回は特別プログラミングなどの経験が無い人でも、SQL
(注:2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注:2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
Mock your back-end API and start coding your UI today.It's hard to put together a meaningful UI prototype without making real requests to an API. By making real requests, you'll uncover problems with application flow, timing, and API design early, improving the quality of both the user experience and API. WithMockaroo, you can design your own mock APIs, You control the URLs, responses, and error c
なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ
ウォンテッドリーでは、「シゴトでココロオドル人の数」の最大化を目指して開発を行なっています。 その上で、このWantedly Visitでは、「MAU」「応募」「売上」を大きな三つの指標としてサービスを運営しています。 サービスによって、分析指標は異なりますが、今回いくつかのデータ分析の基本パターンについて説明したいと思います。 AARRRとはベンチャーキャピタリストである、デイブ・マクルーアが成功するビジネスの構築に必要な「5つの要素」の頭文字からその名前をつけたものです。 具体的には、獲得・アクティベーション・定着・収益・紹介です。 Wantedlyでは初期からこれらの指標をKPIとして定め、開発を行ってきました。これらのAARRRを監視するために必要な分析のパターンを今回ご紹介します。また、特に定着はその中でも最重要でサービスの成長の鍵になります。 7つの分析パターン1. DAU /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く