LiamSQL Server Backup Playbook: From Basics to Advanced StrategiesText by Takafumi Endo SQL Server backup represents a critical component of database management, serving as the primary defense against data loss and system failures.
sqlfmtによって何を解決したいのか
これは何 データ基盤の開発にsqlfmtを導入することについて考えてみたものです。 (チームにsqlfmtを導入するために書いてるものになります) sqlfmtによってどのような課題を解決したいのか 大きくはこれに集約されるかなと思います。 ではスタイル周りにある開発者生産性を阻害する要因とはどのようなものかというと: 読みづらいSQLによるバグの発見の遅れ ロジック周りには関係のない箇所のレビューをする必要性 SQLスタイルのスタンスの違いによる衝突 というものがあります。 これをsqlfmtならどう解決できるかを紹介します。 sqlfmtならどう解決できるか 読みづらいSQLによるバグの発見の遅れ これはそもそもformatterを導入していないことにより生じるものを想定しています。 やたらと長い一行、スペースの無い濃密な一行、揃わないインデント、無意味な改行...などにより、不用意に
すべてのエディタでSQLの自動補完をするためにSQL Language Server(sqls)を作った - Qiita
MySQL互換のパーサーが多い印象ですね。どのSQLパーサーを利用するのが最も適切なのか3日ほど悩みましたが、おそらく1ヶ月悩んでも結論はでないと途中で気が付き、ザラッと中身を見た感じシンプルな作りのxwb1989/sqlparserをチョイスしました。 xwb1989/sqlparserで適当なSELECT文をパースするとAST(Abstract Syntax Tree)が構造体として返却されてきました。ASTとは聞いたことがありますが何なのかは全くわかりません。怖いですね。 ASTが何なのかはわかりませんが、ひとまず中身を解析してみるとSELECT文を読み取ったらSELECT文を表現した構造体に情報を格納しているということはわかりました。構造体を更にたどってみるとこのSELECT文どのテーブルを参照しているのか、JOINしているテーブルは何かなんてこともわかります。これなら補完候補が出
2020年現在のNewSQLについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較
Announcing PartiQL: One query language for all your data | Amazon Web Services
AWS Open Source Blog Announcing PartiQL: One query language for all your data Data is being gathered and created at rates unprecedented in history. Much of this data is intended to drive business outcomes but, according to the Harvard Business Review, “…on average, less than half of an organization’s structured data is actively used in making decisions…” The root of the problem is that data is typ
Java ORマッパー選定のポイント #jsug
2019/01 JSUG勉強会の資料です。 この資料でDisっているのはJPAではなく、 ・何も考えずに「標準だから」というだけでJPAを選ぶ人 ・OSSに全くコントリビュートせずにフリーライドする人 です。Read less
Elasticsearch SQL
Search and analytics, data ingestion, and visualization – all at your fingertips.
JDBCレイヤでDBのシャーディングを行うsharding-jdbcを試してみた - たけぞう瀕死ブログ
DBのデータ量が増えてきた場合の対策の1つとしてユーザIDなどをキーにデータベースを分割するシャーディングと呼ばれる手法があります。これをJDBCのレイヤで実現してしまうsharding-jdbcというライブラリを見つけました。 github.com sharding-jdbcは中国のdangdang（当当）というEC大手企業が開発したOSSで、SQLをパースし、SQLに含まれるシャードキーを抽出して接続先のデータベースや、参照するテーブルを切り替えてくれるというものです。 使ってみる まずはpom.xmlに以下の依存関係を追加します。 <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.4.1</version> </dependency>
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から始まり、日曜日に該当する など挙動に互換性
SQL style guide by Simon Holywell
Overview General Do Avoid Naming conventions General Tables Columns Aliasing or correlations Stored procedures Uniform suffixes Query syntax Reserved words White space Indentation Preferred formalisms Create syntax Choosing data types Specifying default values Constraints and keys Designs to avoid Appendix Reserved keyword reference Column data types SQL style guide Overview You can use this set o
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
SQLアンチパターン
TOPICS Database 発行年月日 2013年01月 PRINT LENGTH 352 ISBN 978-4-87311-589-4 原書 SQL Antipatterns FORMAT 本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
sql.js
https://jp.techcrunch.com/2017/08/30/20170829salesforce-is-using-ai-to-democratize-sql-so-anyone-can-query-databases-in-natural-language/
GitHub - jarulraj/sqlcheck: Automatically identify anti-patterns in SQL queries
Node.js ランタイムに対する自動スケーリングの拡張機能
DBスキーマもバージョン管理したい！
http://jsoniq.org/index.html