MySQLにログインする ログイン方法は以下で詳しく説明しています。 https://qiita.com/momo1010/items/d72d2d567c0768ce2d0d データベースを作成する CREATE DATABASE 作成するデータベースの名前; でデータベースを作成していきます。 例えば以下のようになります。 CREATE DATABASE tweet_app; Query OK, 1 row affected と表示されれば成功です。 次に以下を実行して先ほど作成したデータベースの名前が表示されているか確認しましょう。 SHOW databases; テーブルを作成する データベースの選択 USE 使用するデータベースの名前; を実行します。 例えば以下のようになります。 USE tweet_app; Database changed と表示されれば成功です。 テーブルの作成 CREATE TABLE テーブルの名前 (カラム名やデータタイプ、カラムにつけるオプションなど); を実行します。 CREATE TABLE users (id INT AUTO_INCREMENT, name TEXT, PRIMARY KEY (id)); Query OK, 0 row affected と表示されれば成功です。 テーブルの確認 以下を実行して作成したテーブルの確認をしましょう。 SHOW tables; 先ほど作ったテーブル名が確認できます。 次にテーブル構造を確認してみましょう。 DESCRIBE users;
ログイン方法は以下で詳しく説明しています。 https://qiita.com/momo1010/items/d72d2d567c0768ce2d0d
CREATE DATABASE 作成するデータベースの名前; でデータベースを作成していきます。 例えば以下のようになります。
CREATE DATABASE 作成するデータベースの名前;
CREATE DATABASE tweet_app;
Query OK, 1 row affected と表示されれば成功です。 次に以下を実行して先ほど作成したデータベースの名前が表示されているか確認しましょう。
Query OK, 1 row affected
SHOW databases;
USE 使用するデータベースの名前; を実行します。 例えば以下のようになります。
USE 使用するデータベースの名前;
USE tweet_app;
Database changed と表示されれば成功です。
Database changed
CREATE TABLE テーブルの名前 (カラム名やデータタイプ、カラムにつけるオプションなど); を実行します。
CREATE TABLE テーブルの名前 (カラム名やデータタイプ、カラムにつけるオプションなど);
CREATE TABLE users (id INT AUTO_INCREMENT, name TEXT, PRIMARY KEY (id));
Query OK, 0 row affected と表示されれば成功です。
Query OK, 0 row affected
以下を実行して作成したテーブルの確認をしましょう。
SHOW tables;
先ほど作ったテーブル名が確認できます。 次にテーブル構造を確認してみましょう。
DESCRIBE users;
Docker DesktopをローカルPCにインストール https://www.docker.com/products/docker-desktop お使いの環境(win, mac)に合わせたダウンロードを実行してください。 無事インストールされているか下記コマンドで確認 docker -v これでローカルマシンにDocker Engineが搭載されました。 で、起動しなければ意味がないのでDockerを起動しておいてください。 おそらくクジラのアイコンがどこかにいれば起動していると思います。 ※下記はwindowsのタスクトレイの例 Dockerでの作業は、あくまでもDocker Engineという仮想環境の中での出来事であるということは、常に念頭に置いてください。 「環境はローカルホスト(PC)に構築されているんじゃない、Dockerホスト(Engine)に構築されているんだ」 Pythonをインストールする え？python？何か間違ってませんか？って思った方も多いでしょう。 気持ちは分かります。ただその思いはいったん胸にしまいましょう。 一応、簡単に説明しておくと、 この後、Docker操作を補佐するツールもインストールすることになりますが、 それがPython製のツールなのです。 その名も「Docker Comopose」 そいつを簡単にインストールするにはPythonが話が早いってわけですね。 「python3」「python3-pip」をそれぞれインストールします。 https://www.python.org/ ※pythonをインストールして使える状態に持っていく方法はここでは割愛しますが、 winの方はmacより若干複雑かもしれない。健闘を祈る。 無事インストールされているか下記コマンドで確認 python3 -V Docker Composeをインストールする というわけで、Docker操作の補佐ツールを導入しましょう。 pip3 install docker-compose ※pipはpythonパッケージ管理ツール。nodeでいうところのnpmだと思ってください 無事インストールされているか下記コマンドで確認 docker-compose --version 作業用ディレクトリを作成する ローカルPCの任意の場所に作成し、そのディレクトリへ移動してください。 今回は「wp_test」とします。 コマンドでも、GUIで手動でも何でもいいです。 mkdir ~/wp_test cd ~/wp_test ※いやちょっと待てよ、さっきローカルホスト(PC)で作業するわけじゃない、みたいなこと言ってたけど 作業用ディレクトリをこんな形で作るって何だか矛盾してないかい？って思った方、その指摘は鋭いです。 これはあくまで、「ある作業」用という意味で、これから作る予定のWordpressを利用したプロジェクトの本体の場所を意味しません。 後ほど全貌が明らかになるでしょう。今は静観なさい。 docker-compose.ymlを作成する これは何？って感じでしょうね。 名前からしてあれですが、Docker composeの設定ファイルをYAML形式で書いたものです。 ひとまずエディタで下記内容で作成保存して、先ほど作成した該当ディレクトリに置いてください。 ※YAML形式とは、空白インデントで構造ブロックを表現する記述方法です docker-compose.yml version: "3" services: wordpress-db: image: mysql:5.7 networks: - wordpressnet volumes: - wordpress_db_volume:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: myrootpassword MYSQL_DATABASE: wordpressdb MYSQL_USER: wordpressuser MYSQL_PASSWORD: wordpresspass wordpress-app: depends_on: - wordpress-db image: wordpress networks: - wordpressnet ports: - 8080:80 restart: always environment: WORDPRESS_DB_HOST: wordpress-db WORDPRESS_DB_NAME: wordpressdb WORDPRESS_DB_USER: wordpressuser WORDPRESS_DB_PASSWORD: wordpresspass networks: wordpressnet: volumes: wordpress_db_volume: ※書いてある内容についてはいったん考えずに Docker Composeでコンテナを起動する ひとまずこの設定でコンテナを起動させちゃいましょう。 必ずdocker-compose.ymlを置いたディレクトリで実行してください。 cd ~/wp_test docker-compose up -d ※ここでコンテナが起動しなかった場合、 一つにはDockerEngineそのものが起動しているか再度確認してください。 クジラアイコンがタスクトレイにいればOKです。 起動を確認する http://localhost:8080/ Wordpressの初期インストール画面が表示されるはずです。 コマンドでコンテナの起動確認 docker-compose ps 起動しているコンテナが表示されているはずです。 ※今回は二つ コンテナを停止、破棄する docker-compose down 最後に 「おいおい、こんな駆け足でいって、伏線の回収もなしかよ！」って声が聞こえてきそうですね。 時間も時間なので、今回はここまでだよ。 ひとまずこの状態でWordpressを設定してみて、いろいろいじってみてほしい。 そうすると様々な問題が出てくるだろう。 そしたらまた会おう。
https://www.docker.com/products/docker-desktop お使いの環境(win, mac)に合わせたダウンロードを実行してください。
無事インストールされているか下記コマンドで確認
docker -v
これでローカルマシンにDocker Engineが搭載されました。
で、起動しなければ意味がないのでDockerを起動しておいてください。 おそらくクジラのアイコンがどこかにいれば起動していると思います。 ※下記はwindowsのタスクトレイの例
Dockerでの作業は、あくまでもDocker Engineという仮想環境の中での出来事であるということは、常に念頭に置いてください。
「環境はローカルホスト(PC)に構築されているんじゃない、Dockerホスト(Engine)に構築されているんだ」
え？python？何か間違ってませんか？って思った方も多いでしょう。 気持ちは分かります。ただその思いはいったん胸にしまいましょう。 一応、簡単に説明しておくと、 この後、Docker操作を補佐するツールもインストールすることになりますが、 それがPython製のツールなのです。 その名も「Docker Comopose」 そいつを簡単にインストールするにはPythonが話が早いってわけですね。 「python3」「python3-pip」をそれぞれインストールします。 https://www.python.org/ ※pythonをインストールして使える状態に持っていく方法はここでは割愛しますが、 winの方はmacより若干複雑かもしれない。健闘を祈る。
python3 -V
というわけで、Docker操作の補佐ツールを導入しましょう。
pip3 install docker-compose
※pipはpythonパッケージ管理ツール。nodeでいうところのnpmだと思ってください
docker-compose --version
ローカルPCの任意の場所に作成し、そのディレクトリへ移動してください。 今回は「wp_test」とします。 コマンドでも、GUIで手動でも何でもいいです。
mkdir ~/wp_test cd ~/wp_test
※いやちょっと待てよ、さっきローカルホスト(PC)で作業するわけじゃない、みたいなこと言ってたけど 作業用ディレクトリをこんな形で作るって何だか矛盾してないかい？って思った方、その指摘は鋭いです。 これはあくまで、「ある作業」用という意味で、これから作る予定のWordpressを利用したプロジェクトの本体の場所を意味しません。 後ほど全貌が明らかになるでしょう。今は静観なさい。
これは何？って感じでしょうね。 名前からしてあれですが、Docker composeの設定ファイルをYAML形式で書いたものです。 ひとまずエディタで下記内容で作成保存して、先ほど作成した該当ディレクトリに置いてください。 ※YAML形式とは、空白インデントで構造ブロックを表現する記述方法です
version: "3" services: wordpress-db: image: mysql:5.7 networks: - wordpressnet volumes: - wordpress_db_volume:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: myrootpassword MYSQL_DATABASE: wordpressdb MYSQL_USER: wordpressuser MYSQL_PASSWORD: wordpresspass wordpress-app: depends_on: - wordpress-db image: wordpress networks: - wordpressnet ports: - 8080:80 restart: always environment: WORDPRESS_DB_HOST: wordpress-db WORDPRESS_DB_NAME: wordpressdb WORDPRESS_DB_USER: wordpressuser WORDPRESS_DB_PASSWORD: wordpresspass networks: wordpressnet: volumes: wordpress_db_volume:
※書いてある内容についてはいったん考えずに
ひとまずこの設定でコンテナを起動させちゃいましょう。 必ずdocker-compose.ymlを置いたディレクトリで実行してください。
cd ~/wp_test docker-compose up -d
※ここでコンテナが起動しなかった場合、 一つにはDockerEngineそのものが起動しているか再度確認してください。 クジラアイコンがタスクトレイにいればOKです。
http://localhost:8080/
Wordpressの初期インストール画面が表示されるはずです。
コマンドでコンテナの起動確認
docker-compose ps
起動しているコンテナが表示されているはずです。 ※今回は二つ
docker-compose down
「おいおい、こんな駆け足でいって、伏線の回収もなしかよ！」って声が聞こえてきそうですね。 時間も時間なので、今回はここまでだよ。 ひとまずこの状態でWordpressを設定してみて、いろいろいじってみてほしい。 そうすると様々な問題が出てくるだろう。 そしたらまた会おう。
はじめに rails db:rollbackでマイグレーションファイルをロールバックしようとしたところ、下記のようにUnknownMigrationVersionErrorというエラーに悩まされたので、この解決方法について書こうと思います。 ターミナル rails aborted! ActiveRecord::UnknownMigrationVersionError: No migration with version number 20201230115014. UnknownMigrationVersionErrorの詳細 rails db:migrateでマイグレーションファイルの状態を確認したところ、NO FILEと書かれた身に覚えのないデータが残っていました。これは、statusがupのままVSコード上でマイグレーションファイルを削除してしまったため、DB上には対象ファイルが残っている状態でした。（おそらく、ActiveHashでモデルを作成した時に、skip-migrationを忘れて謝って作成したファイルだと思います...） つまり、対応するファイルが存在しないマイグレーションデータが残ったままになっていたのが、UnknownMigrationVersionErrorの原因でした。 解決方法 1. VSコード上にマイグレーションファイルを作成 まず、NO FILEとなっていたIDが20201230115014のデータに対応するファイルを、VSコード上で作成します。（今回は、「20201230115014.dummy.rb」というファイル名で作成しています。） 2. ステータスをdownにする マイグレーションファイルを作成しただけの状態で、ロールバックしようとすると下記のようにエラーが出ます。これは、先ほど作成したマイグレーションファイルの中身が何も記述されていないことが原因です。 ターミナル rails aborted! NameError: uninitialized constant Dummy これを解消するために、マイグレーションファイルの中身を書いてあげます。その後、一度マイグレートしてあげましょう。 20201230115014.dummy.rb class Dummy < ActiveRecord::Migration[6.0] def change end end ターミナル rails db:migrate この状態で、ロールバックしてあげると、無事ステータスがダウンになりました。 3. 対象ファイルの削除 ここまで来れば、後は対象ファイルを削除するだけです。VSコードで「20201230115014.dummy.rb」のファイルを削除した後、rails db:migrate:statusで確認すると、無事対象のデータが削除できてることが確認できます。 終わりに 何気なく、ステータスを確認せずにマイグレーションファイルを削除すると後々面倒だなと思いました。何か見てくださる方のヒントになれば幸いです。 参考 https://qiita.com/ISSO33/items/33a935cb3255c269bef2
rails db:rollbackでマイグレーションファイルをロールバックしようとしたところ、下記のようにUnknownMigrationVersionErrorというエラーに悩まされたので、この解決方法について書こうと思います。
rails aborted! ActiveRecord::UnknownMigrationVersionError: No migration with version number 20201230115014.
rails db:migrateでマイグレーションファイルの状態を確認したところ、NO FILEと書かれた身に覚えのないデータが残っていました。これは、statusがupのままVSコード上でマイグレーションファイルを削除してしまったため、DB上には対象ファイルが残っている状態でした。（おそらく、ActiveHashでモデルを作成した時に、skip-migrationを忘れて謝って作成したファイルだと思います...） つまり、対応するファイルが存在しないマイグレーションデータが残ったままになっていたのが、UnknownMigrationVersionErrorの原因でした。
まず、NO FILEとなっていたIDが20201230115014のデータに対応するファイルを、VSコード上で作成します。（今回は、「20201230115014.dummy.rb」というファイル名で作成しています。）
マイグレーションファイルを作成しただけの状態で、ロールバックしようとすると下記のようにエラーが出ます。これは、先ほど作成したマイグレーションファイルの中身が何も記述されていないことが原因です。
rails aborted! NameError: uninitialized constant Dummy
これを解消するために、マイグレーションファイルの中身を書いてあげます。その後、一度マイグレートしてあげましょう。
class Dummy < ActiveRecord::Migration[6.0] def change end end
rails db:migrate
この状態で、ロールバックしてあげると、無事ステータスがダウンになりました。
ここまで来れば、後は対象ファイルを削除するだけです。VSコードで「20201230115014.dummy.rb」のファイルを削除した後、rails db:migrate:statusで確認すると、無事対象のデータが削除できてることが確認できます。
何気なく、ステータスを確認せずにマイグレーションファイルを削除すると後々面倒だなと思いました。何か見てくださる方のヒントになれば幸いです。
https://qiita.com/ISSO33/items/33a935cb3255c269bef2
はじめに rails db:rollbackでマイグレーションファイルをロールバックしようとしたところ、下記のようにUnknownMigrationVersionErrorというエラーに悩まされたので、この解決方法について書こうと思います。 ターミナル rails aborted! ActiveRecord::UnknownMigrationVersionError: No migration with version number 20201230115014. UnknownMigrationVersionErrorの詳細 rails db:migrateでマイグレーションファイルの状態を確認したところ、NO FILEと書かれた身に覚えのないデータが残っていました。 これは、ステータスがupのままVSコード上でマイグレーションファイルを削除してしまったため、DB上にはデータが残っている状態でした。（おそらく、ActiveHashでモデルを作成した時に、skip-migrationを忘れて謝って作成したファイルだと思います...） まとめると、対応するファイルが存在しないマイグレーションデータが残ったままになっていたのが、UnknownMigrationVersionErrorの原因でした。 解決方法 1. VSコード上にマイグレーションファイルを作成 まず、NO FILEとなっていたIDが20201230115014のデータに対応するファイルを、VSコード上で作成します。（今回は、「20201230115014.dummy.rb」というファイル名で作成しています。） 2. ステータスをdownにする マイグレーションファイルを作成しただけの状態で、ロールバックしようとすると下記のようにエラーが出ます。これは、先ほど作成したマイグレーションファイルの中身が何も記述されていないことが原因です。 ターミナル rails aborted! NameError: uninitialized constant Dummy これを解消するために、マイグレーションファイル内にクラスとchangeアクションを記述します。その後、一度マイグレートを行います。 20201230115014.dummy.rb class Dummy < ActiveRecord::Migration[6.0] def change end end ターミナル rails db:migrate この状態で、ロールバックしてあげると、無事ステータスがダウンになりました。 3. 対象ファイルの削除 ここまで来れば、後は対象ファイルを削除するだけです。VSコードで「20201230115014.dummy.rb」のファイルを削除した後、rails db:migrate:statusで確認すると、無事対象のデータが削除できてることが確認できます。 終わりに 何気なく、ステータスを確認せずにマイグレーションファイルを削除すると後々面倒だなと思いました。何か見てくださる方のヒントになれば幸いです。 参考 https://qiita.com/ISSO33/items/33a935cb3255c269bef2
rails db:migrateでマイグレーションファイルの状態を確認したところ、NO FILEと書かれた身に覚えのないデータが残っていました。 これは、ステータスがupのままVSコード上でマイグレーションファイルを削除してしまったため、DB上にはデータが残っている状態でした。（おそらく、ActiveHashでモデルを作成した時に、skip-migrationを忘れて謝って作成したファイルだと思います...） まとめると、対応するファイルが存在しないマイグレーションデータが残ったままになっていたのが、UnknownMigrationVersionErrorの原因でした。
これを解消するために、マイグレーションファイル内にクラスとchangeアクションを記述します。その後、一度マイグレートを行います。
テーブルの結合には、 INNER JOIN テーブル名 ON 条件 キーワードを使用 mysql> SELECT * FROM books INNER JOIN chapters ON books.id = chapters.book_id; SELECT * FROM books SELECT * FROM books は単純に books テーブルの一覧を表示 INNER JOIN chapters INNER JOIN chapters が接続されることで、テーブルが結合 ON books.id = chapters.book_id そこで、 ON books.id = chapters.book_id を加えて、この条件に沿わない結合パターンは消す テーブルの結合は一対多、多対多で活躍する
テーブルの結合には、 INNER JOIN テーブル名 ON 条件 キーワードを使用
mysql> SELECT * FROM books INNER JOIN chapters ON books.id = chapters.book_id;
SELECT * FROM books SELECT * FROM books は単純に books テーブルの一覧を表示
INNER JOIN chapters INNER JOIN chapters が接続されることで、テーブルが結合
ON books.id = chapters.book_id そこで、 ON books.id = chapters.book_id を加えて、この条件に沿わない結合パターンは消す
テーブルの結合は一対多、多対多で活躍する
COUNT関数 カウント関数は、レコード数を集計 SUM関数 SUM関数を使うと、合計を表示 AVG関数 AVG関数を使うと、平均を表示
COUNT関数 カウント関数は、レコード数を集計
SUM関数 SUM関数を使うと、合計を表示
AVG関数 AVG関数を使うと、平均を表示
ORDER BY 並べ替え基準となるカラムと指定すると、小さい順に並べ替えて表示させることができます。これはテーブル内の順番が変わるのではなく、あくまで表示上そう見えるようにできるだけです。 mysql> SELECT * FROM bookstore.books ORDER BY price; 大きい順に並べ替えたい場合には、DESCをつけます。 mysql> SELECT * FROM bookstore.books ORDER BY price DESC;
ORDER BY 並べ替え基準となるカラムと指定すると、小さい順に並べ替えて表示させることができます。これはテーブル内の順番が変わるのではなく、あくまで表示上そう見えるようにできるだけです。
mysql> SELECT * FROM bookstore.books ORDER BY price;
大きい順に並べ替えたい場合には、DESCをつけます。
mysql> SELECT * FROM bookstore.books ORDER BY price DESC;
INSERT INTO テーブル名 (カラム1, カラム2, ...) VALUES (値1, 値2, ...); SELECT カラム名 FROM テーブル名; UPDATE テーブル名 SET カラム名1 = 値1, カラム名2 = 値2, ... DELETE FROM テーブル名 mysql> SELECT * FROM bookstore.books WHERE price > 1500; mysql> UPDATE bookstore.books SET price = 1200 WHERE price = 1000; mysql> DELETE FROM bookstore.books WHERE title = "はじめてのCSS";
INSERT INTO テーブル名 (カラム1, カラム2, ...) VALUES (値1, 値2, ...);
SELECT カラム名 FROM テーブル名;
UPDATE テーブル名 SET カラム名1 = 値1, カラム名2 = 値2, ...
DELETE FROM テーブル名
mysql> SELECT * FROM bookstore.books WHERE price > 1500;
mysql> UPDATE bookstore.books SET price = 1200 WHERE price = 1000;
mysql> DELETE FROM bookstore.books WHERE title = "はじめてのCSS";
・Cloud9＋Rails+MySQLでRailsアプリケーションを作成を試みる。 ・MySQLの導入に手間取る。 ・rails newをすでに実行していたため、Gemfileにmysqlを記述し、bundle installを実行するとエラー An error occurred while installing mysql2 (0.5.2), and Bundler cannot continue. Make sure that `gem install mysql2 -v '0.5.2' --source 'https://rubygems.org/'` succeeds before bundling. 手順 https://qiita.com/kumas/items/e2c647dca08fd46b5c7a こちらを参考にアプリケーションの作成をしましたが、知識不足のため、手間取りました。 ①作成したディレクトリに移動して、rails newを実行 ②Gemfileにて gem 'sqlite' #デフォルトのsqliteをMySQLへ変更 gem 'mysql' ③bundle installを実行すると上記エラー ④ sudo yum install mysql-devel で解決するとのことだが、これもエラーで返されてお手上げ。。 解決した方法 sudo apt-get install libmysqld-dev 「そういや、cloud9のenvironments作成時にUbuntu選択してたなぁ。そのエラーかな？」 調べるとそうでした。というか基本的なことがわかってなかった。 https://qiita.com/ryota-0906/items/2da9dcd54a6840b59364 https://qiita.com/hal-bo/items/1e0568120c545bf723c6 Ubuntu環境でパッケージ形式の違うRedHut系のyumコマンド使っていたら、そりゃエラーを返されますよね。 超絶基本的な話ですが、Linuxのパッケージファイルの形式は理解しておかないといけない。
・Cloud9＋Rails+MySQLでRailsアプリケーションを作成を試みる。 ・MySQLの導入に手間取る。 ・rails newをすでに実行していたため、Gemfileにmysqlを記述し、bundle installを実行するとエラー
An error occurred while installing mysql2 (0.5.2), and Bundler cannot continue. Make sure that `gem install mysql2 -v '0.5.2' --source 'https://rubygems.org/'` succeeds before bundling.
https://qiita.com/kumas/items/e2c647dca08fd46b5c7a こちらを参考にアプリケーションの作成をしましたが、知識不足のため、手間取りました。
①作成したディレクトリに移動して、rails newを実行
②Gemfileにて
gem 'sqlite' #デフォルトのsqliteをMySQLへ変更 gem 'mysql'
③bundle installを実行すると上記エラー
④
sudo yum install mysql-devel
で解決するとのことだが、これもエラーで返されてお手上げ。。
sudo apt-get install libmysqld-dev
「そういや、cloud9のenvironments作成時にUbuntu選択してたなぁ。そのエラーかな？」 調べるとそうでした。というか基本的なことがわかってなかった。
https://qiita.com/ryota-0906/items/2da9dcd54a6840b59364 https://qiita.com/hal-bo/items/1e0568120c545bf723c6
Ubuntu環境でパッケージ形式の違うRedHut系のyumコマンド使っていたら、そりゃエラーを返されますよね。 超絶基本的な話ですが、Linuxのパッケージファイルの形式は理解しておかないといけない。
起動 sudo service mysqld start 起動状態確認 sudo service mysqld status 停止 sudo service mysqld stop データベースサーバへの接続 mysql -u root データベースサーバからの切断 mysql> exit データベースの作成 mysql> CREATE DATABASE ？？？; データベース一覧の確認 mysql> show databases; データベースを削除 mysql> DROP DATABASE ？？？; 操作するデータベースを選択 mysql> USE ？？？;
起動
sudo service mysqld start
起動状態確認
sudo service mysqld status
停止
sudo service mysqld stop
データベースサーバへの接続
mysql -u root
データベースサーバからの切断
mysql> exit
データベースの作成
mysql> CREATE DATABASE ？？？;
データベース一覧の確認
mysql> show databases;
データベースを削除
mysql> DROP DATABASE ？？？;
操作するデータベースを選択
mysql> USE ？？？;
データベースは、たくさんのデータを一元管理し、データの保存、取得することに特化したソフトウェア（ミドルウェア）。データベースは データを永続的に保存 するのに適している。アプリケーションはデータを処理しますが、保存することができない。 最も利用されている種類はリレーショナルデータベース。リレーショナルデータベースを管理するシステムを、リレーショナルデータベース管理システム（RDBMS） リレーショナルデータベースの特徴には下記の3つ。 ・テーブルは、カラム(縦)とレコード(横)で構成される ・カラムに、保存されるデータの制約を設定できる ・データの保存や取得などの処理に、SQLという言語を使用する。 ユーザーテーブル(users)から全員分の名前(name)を取得するには、下記のような命令文。 select name from users;
データベースは、たくさんのデータを一元管理し、データの保存、取得することに特化したソフトウェア（ミドルウェア）。データベースは データを永続的に保存 するのに適している。アプリケーションはデータを処理しますが、保存することができない。
最も利用されている種類はリレーショナルデータベース。リレーショナルデータベースを管理するシステムを、リレーショナルデータベース管理システム（RDBMS）
リレーショナルデータベースの特徴には下記の3つ。
・テーブルは、カラム(縦)とレコード(横)で構成される ・カラムに、保存されるデータの制約を設定できる ・データの保存や取得などの処理に、SQLという言語を使用する。
ユーザーテーブル(users)から全員分の名前(name)を取得するには、下記のような命令文。
select name from users;
