タグ

dbに関するissmのブックマーク (230)

  • ODBCドライバーとは? ODBCの仕組みからドライバーの使い方まで解説!

    企業が業務システムにMySQL、PostgreSQLOracleSQL Server といったリレーショナルデータベースを使いはじめてから今に至るまで、データベースへのコネクティビティは重要な課題であり続けています。1992年にMicrosoft が発表したOpen Database Connectivity(ODBC)API は、この課題に対する画期的な解決策となりました。 ODBC は、アプリケーションと多様なデータベース間の接続を標準化する技術として、現在でも広く採用されています。記事では、ODBC 技術の仕組みとODBC ドライバーの役割、その重要性について詳しく解説します。 ODBC の仕組み ODBCとは ODBC は、アプリケーションからデータベースへのアクセスを標準化するためのAPI です。ODBC 4.0 の仕様はこちらに定義されています。この技術により、アプリケー

    ODBCドライバーとは? ODBCの仕組みからドライバーの使い方まで解説!
    issm
    issm 2024/10/25
  • sq

    sq is a free/libre open-source data wrangling swiss-army knife to inspect, query, join, import, and export data. You could think of sq as jq for databases and documents, facilitating one-liners like:

    sq
    issm
    issm 2024/10/07
  • データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。

    回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

    データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
  • データベース概論Ⅰ | 筑波大学オープンコースウェア|TSUKUBA OCW | 北川博之

    データベースシステムに関する入門。データベースの基概念、データモデリング、リレーショナルデータモデル、データベース言語SQL、リレーショナルデータベース設計論、物理的データ格納法、問合せ処理等について講述する。 (2018年度) 【教科書】 「データベースシステム」(北川博之著、オーム社) 北川 博之筑波大学 計算科学研究センター教授1978年東京大学理学部物理学科卒業。1980年同大学理学系研究科修士課程修了。日電気(株)勤務の後、筑波大学電子・情報工学系講師、同助教授を経て、現在、筑波大学計算科学研究センター教授。理学博士(東京大学)。データベース、データ統合、データマイニング、ストリーム処理、情報検索、ビッグデータ等の研究に従事。著書「データベースシステム」(オーム社)等。日データベース学会会長、ACM SIGMOD日支部委員長等を歴任。情報処理学会フェロー、電子情報通信学会

    データベース概論Ⅰ | 筑波大学オープンコースウェア|TSUKUBA OCW | 北川博之
    issm
    issm 2024/01/01
  • オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ

    こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした(幸いすぐにキャンセルして事なきを得ました)。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確

    オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
    issm
    issm 2023/10/23
  • MySQLとインデックスと私

    2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…

    MySQLとインデックスと私
  • time_zone設定の違うMySQLのレプリケーションについて - 角待ちは対空

    結論としてはできない。正確にはレプリケーションの設定自体はできるがデータが適切に複製されないので設定を変える必要がある。 これはMySQL5.6 -> Aurora(MySQL5.6互換)移行の際、レプリケーションを組んだが、時刻周りで上手くいかなかった問題と解決の記録。 そして、はてなエンジニア Advent Calendar 2018の2日目の記事です。 qiita.com 前提 件の移行の際のmaster以下のような設定だった。 mysql> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +-

    time_zone設定の違うMySQLのレプリケーションについて - 角待ちは対空
  • MySQLの物理削除によるパフォーマンスの悪化とその回避策について

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめまして、Yahoo!ショッピングでシステム開発を担当している村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える巨大なDBの運用の中で遭遇したMySQLのアンチパターンと、回避した方法について紹介いたします。 特定のテーブルをJoinするとすごく遅くなる Yahoo!ショッピングでは商品を出品するためのツールがあります。 商品情報には「商品名」「価格」といった、任意で設定可能な項目のほか、「ブランド」「商品種別」など、製品ごとに入力する内容が決まっている項目を、マスター情報としてテーブルで管理しています。 このマスター情報を利用して、出品の際に入力情報が正確であるかどうか確か

    MySQLの物理削除によるパフォーマンスの悪化とその回避策について
  • JSON型にindexも!MySQL 5.7のGenerated Columnsの可能性について探る - UUUMエンジニアブログ

    nazoです。 今回はMySQL 5.7の新機能であるGenerated Columnsについて紹介したいと思います。 Generated Columnsとは? 簡単に言うと、トリガーで特定のカラムにデータを入れるのを簡単に定義する方法みたいなもので、カラム定義時にAS 計算式と書くことで、そのカラムの値が該当の計算結果になります。 この機能はMySQL 5.7.6から追加されました。日語では「生成列」と呼ぶこともあるようです。 基的な使い方 リファレンスに書いてあるクエリを実行してみましょう。 mysql> CREATE TABLE triangle ( -> sidea DOUBLE, -> sideb DOUBLE, -> sidec DOUBLE AS (SQRT(sidea * sidea + sideb * sideb)) -> ); Query OK, 0 rows af

    JSON型にindexも!MySQL 5.7のGenerated Columnsの可能性について探る - UUUMエンジニアブログ
    issm
    issm 2021/04/02
  • MySQLに緯度経度を保存する際の、カラム型の選び方 - Qiita

    はじめに 数値を丸められること無く、記録したとおりに緯度経度情報を保存したい。 もちろん文字列型ではなく浮動小数点型を使う方が処理効率が良いですよね。 どのようなカラムを使えば意図通りに保存出来るのかまとめてみました。 結論 VARCHAR型やDECIMAL型を利用する手もありますが、どちらも計算コストが高いため、 基的にdouble(9,6)を利用すれば問題ないでしょう。 最大値と最小値 それぞれの最小値と最大値は次の通りです。 緯度 (latitude) : -90 〜 90 経度 (longitude) : -180 〜 180 小数点桁数と精度の関係 どの程度の精度を求めるには、どの程度の桁数が必要となるか、まとめてみましょう。 ざっくりと計算しますと地球の円周は約40,000,000mで 緯度はぐるっと360度ですから緯度1度は 40000000/360≒111111.1111

    MySQLに緯度経度を保存する際の、カラム型の選び方 - Qiita
  • Redis、PostgreSQL、MySQLで近傍検索

    「サーバーで付近の情報を通知するサービスのつくり方」 という、Geohashを使って近傍検索を実現する記事をみつけました。 最近Redisに関する記事を書いた関係で、 この記事をみて「GeohashはRedisと一緒に使うともっと便利だよ!」と思わず宣伝したくなったのですが、 MySQL5.7でInnoDBに空間インデックス(Spatial Index)のサポートが入ったので 「MySQLでももっと簡単にできるのでは?」と思い、 RedisやMySQLを含めたいろんなDBで近傍検索を実現する方法を調べてみました。 以前、スマートフォンのセンサを活用して花火の打ち上げ場所を推定するアプリを作った関係で、 地球上での距離計算の実装も気になったので、それについても調査してみました。 関連知識 GeoHash Geohash(ジオハッシュ) は緯度・経度を短い文字列に変換する方法です。 距離が近い

  • MySQLのトランザクション制御がキモい話 - なからなLife

    MySQL Casual Advent Calendar 2016 - Qiitaの5日目の記事です。 AdventCalendar自体初参加でドキドキ。 トランザクションの開始は、BEGINしたときじゃない! MySQLでは、BEGIN(START TRANSACTION。長いので、以下、特筆すべき場合以外は「BEGIN」で)を宣言しても、内部的にはまだトランザクションを開始してません。 SQLを投げたタイミングで、トランザクション開始になります。 このとき、更新のない、FOR UPDATEもないSELECT文でも、トランザクションが開始されます。 なにそれきもい。 「AutoCommit=ON/OFF」による違い AutoCommit=ONのとき トランザクションはSQLを発行するたびにBEGIN/COMMITで完了し、ロールバックできません。 複数SQLを束ねて1つのトランザクション

    MySQLのトランザクション制御がキモい話 - なからなLife
    issm
    issm 2021/02/19
  • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

    自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

    1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
    issm
    issm 2020/11/05
  • MySQL :: MySQL Terminology Updates

    Why was “source” chosen? MySQL Asynchronous Replication is a change stream. Each replication configuration has a source and does not imply what role a server should have in the overall database architecture. Therefore, the use of e.g. “primary” does not fit, especially when replication is used to build database architectures topologies including bidirectional replication, multi-tiered replication,

  • MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump絵文字が消えていないか要チェック mysqldumpError 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク

    MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
    issm
    issm 2020/10/27
  • MySQLのZero Dateへの対処法

    MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー

    MySQLのZero Dateへの対処法
    issm
    issm 2020/06/16
  • MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳

    結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:

    MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
    issm
    issm 2020/06/16
  • データベース設計の際に気をつけていること - 食べチョク開発者ブログ

    皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ!”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

    データベース設計の際に気をつけていること - 食べチョク開発者ブログ
  • マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで

    マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで マイクロソフトは、分散NoSQLデータベース「Azure Cosmos DB」が期限なく無料で使える「Free Tier」を発表しました。 Activate Free Tier on a new #azurecosmosdb account to get 400 RU/s throughput and 5 GBs storage free each month, for the life of your account. What will you build? #appdev #nosql https://t.co/BmfoWyYcbW — Azure Cosmos DB (@AzureCosmosDB) March 7, 2020 Azure

    マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで
  • SQLのインデックスとそのチューニングについてのオンラインブック

    開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQLOracleSQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 Db2 (LUW)U

    SQLのインデックスとそのチューニングについてのオンラインブック