並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 17 件 / 17件

新着順 人気順

NoSQLの検索結果1 - 17 件 / 17件

  • データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)

    これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気!! 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍(とか)を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ

      データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)
    • 無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita

      はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基本的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ

        無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita
      • サブクエリの書き方を2万文字弱かけてすべて解説する

        これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

          サブクエリの書き方を2万文字弱かけてすべて解説する
        • Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル) - Qiita

          Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル)oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた!』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか? 帳票や大きな画像ファイルなどを扱う際、大きく分けて2つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなどをDBに保存する オライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz

            Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル) - Qiita
          • リーダブルSQL[より良いSQLを書くためのシンプルで実践的なテクニック] - Qiita

            はじめに 最近エンジニア界隈では「リーダブルコード」が話題なっていますね。 リーダブルコードでは、このような定理が紹介されています。 「コードは他の人が最短時間で理解できるように書かなければいけない。」 Dustin Boswell リーダブルコード P.3 より引用 SQLでも同じことが言えそうです。 リーダブルなSQLを書いてないと結婚できない時代が今まさに到来しようとしています。 皆さん、クソSQL1を読んだことがありますね? クソSQLを書いたことがありますね? 僕は、あります。 そこで、本記事ではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。 処理の流れの順に上から読めるようにする 人間のメンタルモデルは、問題やタスクを小さなステップに分割し、それぞれを順番に実行することに適しています。 サブクエリを使ったSQLでは、処理の流れは上から下ではなく、ネストされた

              リーダブルSQL[より良いSQLを書くためのシンプルで実践的なテクニック] - Qiita
            • 履歴データテーブルとの向き合い方_PHPerKaigi2024

              PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

                履歴データテーブルとの向き合い方_PHPerKaigi2024
              • SQL滅ぶべし | ドクセル

                SQL • リレーショナルデータベースシステムと会話するための言語 • 1970年 Codd が RDB モデルと同時に提案 (Alpha言語) • 1974年 Chamberlin と Boyce が改良 • 元々は SEQUEL (Structured English Query Language) だったが、商標登録されていた • 読み方は エスキューエル とそのまま読む (Glliespie 2012)

                  SQL滅ぶべし | ドクセル
                • 世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」を開発

                  世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気(株)と(株)ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」(以下、委託事業)において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」(以下、劔)を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境(メニーコア・大容量メモリーなど)に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン

                    世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」を開発
                  • RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag

                    PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134

                      RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
                    • DynamoDBでできないこと

                      この記事について 本記事は、筆者が普段AWSの各種サービスを使って感じた感想・気づきをもとに、クラウドアーキの設計やサービスのより良い使い方Tipsを考察するシリーズです。 第二弾も第一弾に引き続きDynamoDBについてです。 DynamoDBはkey-value型のNoSQLであり、従来よく使われていたRDBとは異なるDB特性・クエリ特性を持っています。 そのためRDBを設計するときと同じようなノリでスキーマ設計・テーブル設計を行うと、後から「この操作をやらせるならDynamoDBじゃないほうが良かったんじゃないか?」ということが発覚しがちです。 本記事では筆者が遭遇した「DynamoDBでやらせてみたら苦労した・できなくて設計変更を強いられた」というユースケースをまとめることで、DynamoDBのクエリ特性や適性を考察することを目指します。 使用する環境・バージョン 2024/1/1

                        DynamoDBでできないこと
                      • DynamoDBのベストプラクティスを技術的詳細から理解する

                        こんにちは。 株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 弊社では宿泊施設様向けに宿泊施設の予約管理用のSaaSを提供しており、現時点で1000近くの施設様にご利用いただいています。 現在、これまでに溜め込んだ日本最大級の宿泊コンテンツの検索エンジンを構築しており、その過程でさまざまなデータベースを探索しています。 本記事では、AWSのKVSであるDynamoDBを題材に、公式ドキュメントに書かれているキー設計のベストプラクティスの背景を理解することを目的とします。 なお、本記事の執筆にあたって、こちらの動画を大変参考にさせていただきました。 DynamoDBとは DynamoDBとは、AWSで利用できる、あらゆる規模に対応する高速で柔軟なNoSQLデータベースサービスです。 DynamoDBが登場した背景は、アプリケーションの大規模化です。

                          DynamoDBのベストプラクティスを技術的詳細から理解する
                        • CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?

                          CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?

                            CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?
                          • 【SQL】ちょっとしたパフォーマンスチューニングまとめ - Qiita

                            SELECT table_a.id, table_a.name FROM table_a INNER JOIN table_b ON table_a.id = table_b.id; メリットとしては、 どちらかのテーブルのid列のインデックスを使用可能 サブクエリがないことで中間テーブルが作成されない しかし、インデックスがない場合はEXISTSの方が良い場合があります ソートの回避 SQLでは暗黙的にソートが発生する演算が存在するので、 パフォーマンスにも影響するため、ソートが必要ない場合は考慮する必要があります ソートが発生する演算 GROUP BY句 ORDER BY 句 集約関数(SUM, COUNT, AVG) DISTINCT 集合演算子(UNION, INTERSECT, EXCEPT) ウィンドウ関数(RANK, ROW_NUMBER 等) メモリ上でのソートだけではなく

                              【SQL】ちょっとしたパフォーマンスチューニングまとめ - Qiita
                            • PayPalが1日3,500億回のリクエスト処理を支えるキーバリューストアをオープンソース化

                              Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                PayPalが1日3,500億回のリクエスト処理を支えるキーバリューストアをオープンソース化
                              • 3値論理

                                なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか? これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま

                                • MySQL即効クエリチューニング読んだ - $shibayu36->blog;

                                  MySQL即効クエリチューニング ThinkIT Books 作者:yoku0825インプレスAmazon 最近クエリチューニングの仕事があったので、少し深めに知ろうと読んだ。 MySQLの内部構造がどうなっているかは置いておいて、どうすればクエリの問題を把握できるかが素早く知れる良い本だった。90ページくらいですぐ読めるのも良い。個人的にはHandler_%変数を使った調査、innotopによる状況可視化、sys.innodb_lock_waitsによるロック状況の可視化あたりが非常に参考になった。 ちなみにさらに内部構造に踏み込んで理解しようとするなら、以下の記事がおすすめ。 雑なMySQLパフォーマンスチューニング MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ Rails Developers Meetup 2018 で

                                    MySQL即効クエリチューニング読んだ - $shibayu36->blog;
                                  • GoでSQLの複雑なクエリのテストを書いてみた - ZOZO TECH BLOG

                                    はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの佐野です。普段はサーバーサイドエンジニアとして、FAANSのバックエンドシステムを開発しています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗で働くショップスタッフの販売サポートツールです。例えば、コーディネート投稿機能や成果確認機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイトへの連携が可能です。成果確認機能では、投稿されたコーディネート経由のEC売上やコーディネート閲覧数などの成果を可視化しています。 本記事では、成果データの集計処理におけるBigQueryのクエリ実行処理のユニットテストをGoで実装した取り組みと、その際の工夫についてご紹介します。 目次 はじめに 目次 成果データの集計処理とは 抱え

                                      GoでSQLの複雑なクエリのテストを書いてみた - ZOZO TECH BLOG
                                    1