質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

解決済

4回答

1023閲覧

【SQL初心者】日付カラムを基点に条件を絞る方法

iki

総合スコア12

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

0グッド

0クリップ

投稿2018/03/12 02:44

編集2018/03/13 02:50

【やりたいこと】
下記のようなポイント履歴のテーブルがあり、
・日付カラムの項目から遡って3カ月以内にポイントが使われていないユーザー ⇒新規ユーザー
・日付カラムの項目から遡って3カ月以内にポイントが使われているユーザー  ⇒既存ユーザー
といったフラグをテーブルに追加したい。

〈ポイント履歴のテーブル〉
・日付カラム
・ユーザーiD
・ユーザーポイント      ←日付カラム時点での付与されたポイントを示してます
・ユーザーの属性
(・作成したいフラグ)

また、実行計画としては、
・ポイント履歴からフラグを追記
・他のテーブルに、ユーザーiDやキャンペーンID、キャンペーンデバイスなどのキャンペーン周りのテーブルがあるので、ユーザーidにて紐づけて、キャンペーン内容、キャンペーン期間ごとのユーザーの抽出を行いたいと思ってます。

【困っている点】
各々の各行で日付項目を確認し、その日付範囲から3カ月以内のユーザー履歴を確認する、といったことの実現方法がわからず困ってます。

・年月日のカラム内の日時から3カ月以内をフラグ付与の期間としたいです。
⇒テーブルには同一ユーザーIDが複数あるため、その各々の"各行"の年月日で抽出したいと思っております。

・フラグの付与は、どのようにつけますか? & フラグ付けの要件について
⇒各Ptがすべて0orNULLでない場合 ⇒ 新規会員
各PtでどこかのPtカラムに値あり ⇒ 既存会員
といった新規/既存会員のカラムをテーブルに追加したいです

現状、下記のように、初回日付で必ず"新規"の扱いとなってしまっているため、原因を教えて頂きたいです。(初回日付であっても、ポイントがある場合は"既存"の扱いとしたいです)
date user_id pt flag
20171001 a 10 新規  
20171007 a 20 既存
20171015 a '' 既存
20171025 a 40 既存

【実行環境】
Windows
Postgre(pgAdmin4内のクエリツールよりクエリを書いてます) を利用しています。

【現状】
皆様から頂いた回答より、
・serialをPKに設定したテーブルを作り直し
・インデックスをdateとuser_idに設定
・下記クエリを実行(処理時間はかかりますが、結果はでます)

困っている点 が現在の状態になります。

〈現時点での実装内容〉
select *, case when exist_point>0 then '既存' else '新規' end as new_or_existing
from (
select *
,(select sum(coalesce(fuyo_pt_tj,0)+coalesce(kan_pt_tj,0)+coalesce(kan_pt_kg,0))
from point_rireki2
where user_id=main.user_id and "date" >= main."date" - interval '3 months' and "date" < main."date"
) as exist_point
from point_rireki2 main
) step1
order by user_id, date

【参照】
回答頂いた方から、このようなURLで共有できるものを教えていただきました。
まさに、このような感じのデータとなります。(属性は、細かく記載させていただくと年齢や性別などのデータです。userポイントは、その日付時点で付与されたポイントになります)
http://sqlfiddle.com/#!17/72bf4/1

【追記】
対象のオブジェクトとそのバイトですが、
・object name: point_rireki
・bytes text : 68,108,288
*下記参考に、上記情報を追記しました
http://dqn.sakusakutto.jp/2011/11/postgresql.html

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

alg

2018/03/12 03:57

"ポイント履歴のテーブル" の "ユーザーポイント"列は、その時点でのユーザーのポイントですか?それともその時点でユーザーが使用したポイントですか?
alg

2018/03/12 03:58

可能であればテーブルレイアウト(というかcreate table)を明記すると、回答が得られやすくなるかもしれません。あるいは、簡易的に状況を再現する環境を提示するとか。例えば sqlfiddle(http://sqlfiddle.com/#!17/72bf4/1)
iki

2018/03/12 04:08

ありがとうございます!上記のようなサービスで共有できるのですね。知らなかったです。 attributeの内容は、性別や年齢等々あるのですが、主な内容はこのような形です。また、ポイントは、そのdate時点でのユーザーのポイントになります。
sazi

2018/03/12 04:37

性能に関してはインデックスの情報も必要です。それから可能なら実行計画も質問に追記したほうがいいですね。
iki

2018/03/12 05:01

ありがとうございます!下記を参考に、インデックス情報を調べて追記させていただきました。もしご指摘頂いた内容とずれていたら教えて頂きたいです!よろしくお願いします。参照URL:http://dqn.sakusakutto.jp/2011/11/postgresql.html
guest

回答4

0

全体でやりたいことが質問本文から読み取れなかったのですが核心部分だけは答えられそうなので。

ポイント履歴レコードに、それが新規ユーザーに該当するかどうかの判定をします。

sql

1SELECT 2 main.*, 3 CASE WHEN EXISTS ( 4 SELECT 1 5 FROM ポイント履歴 sub 6 WHERE sub.日付 > main.日付 - interval'90 days' -- 「3ヶ月前」のSQL表現についてはお使いのDBに合わせて 7 AND sub.日付 < main.日付 8 AND main.ユーザーid = sub.ユーザーid 9 ) THEN '既存' ELSE '新規' END AS new_or_existing 10FROM 11 ポイント履歴 main

ポイント履歴テーブルにインデックス「ユーザーid, 日付」が張ってあると良いです。

12:41 サブクエリ内の日付条件を修正

投稿2018/03/12 03:03

編集2018/03/12 03:40
yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

iki

2018/03/12 03:31

ありがとうございます! やりたかったことは、 ・ポイント履歴のテーブルに、新規と既存のフラグを抽出し ・抽出したフラグを他テーブルの項目と結合した際の条件に使用して、データを抽出 といったことを想定していました。 (sql初心者的な質問となってしまって恐縮ですが) サブクエリの中でやっていることを伺いたいのですが、 SELECT 1 というのは、1以上のポイントを探している、、、ということなのでしょうか?
yuba

2018/03/12 03:41

あ、日付条件が普通に間違っている⋯直しました。 1は完全にダミーです。 このサブクエリ(「このレコードと同じユーザーIDで日付が古く、3ヶ月前以降のもの」)が1件でも意味のある結果を返せばEXISTSは真になるとしたいので、何か意味のある値として最も簡単な1を返してもらっているだけです。
iki

2018/03/12 03:59 編集

ありがとうございます! >このサブクエリ(「このレコードと同じユーザーIDで日付が古く、3ヶ月前以降のもの」)が1件でも意味のある結果を返せばEXISTSは真になるとしたいので 上記だと、  ・日付カラム内の日付から三ヵ月以内に、特定ユーザーがポイントを使っているかどうか といった条件がないように感じたのですが、サブクエリ内の結果で、三ヵ月以内にポイントの利用の有無を絞っている、、、感じなのでしょうか? 下記の2行で、"三ヵ月以内"を絞っている、、ということで合ってますでしょうか?ポイント利用の有無は抽出されてない認識で合ってますでしょうか?(初歩的ですいません... ) WHERE sub.日付 > main.日付 - interval'90 days' -- 「3ヶ月前」のSQL表現についてはお使いのDBに合わせて AND sub.日付 < main.日付
iki

2018/03/12 04:14

また、回答頂いたクエリを動かしたところ、実行時間が長くなかなか結果が返らない形なのですが、 何か伝え漏れている点などありますでしょうか.... (ファイルサイズは、4万KB程になります)
yuba

2018/03/12 04:55

sub.日付 < main.日付 で該当レコードより古いレコードだけに限定し、 sub.日付 > main.日付 - interval'90 days' 該当レコードの3ヶ月前よりは新しいものに絞っています。 実行時間がかかるのは、インデックスが張られていないためではと思います。 とは言え、サービス中のDBでいきなり巨大なテーブルにインデックスを張ると大変なことになりますのでご注意ください。(インデックスの生成には時間がかかり、その間書き込みアクセスがすべてブロックされます。) 単発のレポートならコピーを作って、そのコピーしたテーブルにインデックスを張る、の順番でやることになります。 アプリの機能としてその問い合わせがやりたいとなるといろいろ大変なんで、専用の集計テーブルを別に用意してですかね。
guest

0

ベストアンサー

ポイント履歴というのは、ポイントが付与された場合にデータが追加されるということで良いですか?

で要件としては、各行に対して過去3カ月以内にポイントが付与されているかということであれば、
日付順でみて直前のデータが3カ月以内かどうかを判断すればいいので、Window関数が使用できます。

SQL

1select *, case when lag_date >= "date" - interval'3 months' then '既存' else '新規' end as new_or_existing 2from ( 3 select *,lag("date") over(partition by user_id order by "date") lag_date 4 from point_rireki 5) step1

尚、性能を考えた場合には(user_id, date)のインデックスがあればよいかと。
※上記はプライマリーとして定義されている気もしますので、そうであれば敢えて追加の必要はありません。
追記(ポイントでの判断)

SQL

1select *, case when exist_point>0 then '既存' else '新規' end as new_or_existing 2from ( 3 select * 4 ,(select sum(point) 5 from point_rireki 6 where user_id=main.user_id and "date" >= main."date" - interval '3 months' and "date" < main."date" 7 ) as exist_point 8 from point_rireki main 9) step1 10order by user_id, date

これだと結局性能はインデックス次第だと思います。

投稿2018/03/12 05:11

編集2018/03/12 07:55
sazi

総合スコア25138

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

iki

2018/03/12 06:06 編集

ありがとうございます!今度は実行計算の時間がかからず、結果を出力することができました。 lag関数を初めて知りまして、右記で確認しながら読み解いております。(http://kuwalab.hatenablog.jp/entry/20130218/1361158028) 内容についてお伺いしたいのですが、 ・中のサブクエリ(で合っておりますでしょうか..)で定義したstep1というのは、どこで呼び出されているか教えていただけないでしょうか.... ・case when lag_date >= "date" の "date"部分は、どこで定義されたテーブル内容を取得しにいっているのでしょうか.... 初歩的ですいませんが、よろしくお願い致します。。。
sazi

2018/03/12 05:50 編集

・step1はfrom句でのサブクエリーには名前を付ける必要があるので、適当です。 参照で、この名称は省略しています。 ・step1の内容です。※厳密にはpoint_rireki。 "を付けたのはdateが予約語ぽいので付けました。無くてもエラーにはなりませんが。
iki

2018/03/12 07:20

>サブクエリーには名前を付ける必要があるので そうなんですね!ありがとうございます! もう1点、お伺いしたいのですが、本件の場合、 window関数で、ユーザーIDの初回の行データには、必ず"新規"となっているかと思うのですが、 過去3カ月の履歴におけるポイントの有無のみで新規と既存を切り分ける場合はどうすればよいのでしょうか。(case when のところで、and で条件を足す感じになりますでしょうか....) 例: date user point flag 20170101 A '' 新規 20170201 B 100 既存 20170201 A 10 既存 20170515 B ''  新規
sazi

2018/03/12 07:28

>過去3カ月の履歴におけるポイントの有無のみで 過去3カ月以内のポイント計>0ということですか?
iki

2018/03/12 07:38

>>過去3カ月の履歴におけるポイントの有無のみで >過去3カ月以内のポイント計>0ということですか? 各行のdateカラムから三ヵ月以内の間に、 ポイントがすべて0 or NULL →新規会員 ポイントに値あり     →既存会員 といったケースとなります。 ですので、(各行にて)過去3カ月以内のポイント計>0 という形となりますでしょうか (度々伺ってしまって恐縮です...)
iki

2018/03/12 07:47

また、新規に作成したフラグをテーブルにも追加すべく、下記を参考に insert into point_rireki をselect文の前に入れたのですが、カラムが追加されません。。 こちらの原因も教えて頂けないでしょうか。よろしくお願いいたします。 〈参考にさせて頂いたサイト〉 https://www.projectgroup.info/tips/SQLServer/SQL/SQL000001.html
sazi

2018/03/12 07:53

であれば、1行に対して都度、問い合わせが必要になるので、window関数では対応できないですね。 サブクエリーで行うことになります。 追記しました。
sazi

2018/03/12 07:58

フラグって今回の判定結果を格納するフラグということですか? もしそうなら、ポイント履歴が変更される度に更新が必要になりますので、止めたほうが良いかと。
iki

2018/03/12 08:06

>フラグって今回の判定結果を格納するフラグということですか? はい、そうなります! なるほど、テーブルに型として追加してしまうと確かに更新処理がやっかいですね。 他のテーブルと結合する場合もこのクエリを流用しながら、joinする方向でやってみようと思います。
iki

2018/03/12 08:13

>これだと結局性能はインデックス次第だと思います。 本件、回答の追記および、コメント頂きありがとうございます。 現状、インデックスの設定をしておらず、テーブルと各カラムの設定しかできておりません。 (そのためだと思うのですが、頂いたクエリを実行すると、処理ができませんでした) また、実は、ポイントが複数ポイントありまして、その場合sumの処理をどうすればよいでしょうか。(初めから複数ポイントの内容を記載しておくべきでした..すいません...) 【伺いたい点】 ・今回の場合におけるインデックスの設定内容に関して ・複数ポイントの場合の sum(point) の処理について   ポイントが、     ・user_fuyoPT (付与ポイント)     ・user_kgnPT(還元ポイント)   の2種類存在しており、その合計を、 sum(point) としたいと思っております。
sazi

2018/03/12 08:57

user_fuyoPT,user_kgnPT共にNullが無いなら、 sum(user_fuyoPT+user_kgnPT) で良いかと。 Nullがあるなら、 sum(coalesce(user_fuyoPT,0)+coalesce(user_kgnPT,0)) ですね。
sazi

2018/03/12 09:03

インデックスの前にプライマリーキーの設定を行って下さい。 プライマリーの想定は(user_id,date)です。 但し、既にデータがあるのでしょうから、同一日に複数のポイントを付与されているようなデータがある場合には、重複が発生しますので、設計自体の見直しが必要です。 (キー構成を変更するとか、追加や更新の処理を見直すとか)
iki

2018/03/12 09:09

ありがとうございます。 Null項目があるので、2番目を利用しようと思います!
iki

2018/03/12 09:25

>インデックスの前にプライマリーキーの設定を行って下さい。 >プライマリーの想定は(user_id,date)です。 >同一日に複数のポイントを付与されているようなデータがある場合には、重複が発生しますので、設計自体の見直しが必要です。 ありがとうございます! ご指摘頂いた通り、下記のようなデータのため、主キーにできるようなカラムが存在しないデータとなってます。 そのため、主キーの設定をせずに、テーブル・カラム作成→データのインポートを実施しておりました。 このような場合、主キーとなるような新規の項目を追加する形になるのでしょうか。 また、インデックスは、主キーの設定後に、下記のような形で作成する認識であっていますでしょうか。 create index userindex on point_rireki(user_id); 〈本件データの例〉 date user user_fuyoPT user_kgnPT 20171001 a '' 10 20171001 b '' '' 20171015 a 200 30 20171015 b 430 60 20171015 b 30  ''
sazi

2018/03/12 09:41

重複があるデータで、追加しかしないテーブルであれば、主キーを設定しないことも止む無しというケースもありますが、主キーは必ず設定したほうが良いですね。 一意にするものが無い場合、一意な更新ができませんので。 今回の場合であれば、serial値のカラムをサロゲートキーとしておいた方が良いでしょうね。 create indexについては文法的には問題ありません。
iki

2018/03/12 10:50 編集

>今回の場合であれば、serial値のカラムをサロゲートキーとしておいた方が良いでしょうね。 すいません...上記の方法がわからず、教えていただけないでしょうか。 (カラム作成時には特に記述していない、システムのserial値を呼び出すということだと思うのですが、どう設定すると、そうなるのかがわからず) *サロゲートキーに関しては、下記を読んで理解を致しました。 http://dbflute.seasar.org/ja/manual/topic/dbdesign/surrogatekey.html#surrogatekey indexの設定については、user_idとdateが今回のデータ抽出上、設定しておくと、追記頂いたクエリが(処理速度的な観点でも)実行できるのではないかと思ってますが、合っておりますでしょうか。 以下の順で進めようと思っています! ・serial値のカラムをサロゲートキーする ・user_idとdateをそれぞれ indexに設定する ・追記で記載頂いたクエリを実行し、処理速度的に大丈夫かどうかを試してみる
sazi

2018/03/12 14:14

テーブル定義の例としては、以下になります。 create table point_rireki ( no bigserial, "date" date, user_id int, point int, attribute int, CONSTRAINT point_rireki_key PRIMARY KEY (no) ) insertの際に上記だと「No」を省略すると自動で設定されます。 因みに、現状では大体何件位のデータなのでしょう?
iki

2018/03/13 00:27

行数で、約1,050,000行(*dateと一部のポイントのみ入っている行も含める形です)になります。 大きさは、40,000KB程です。 一旦、テーブルを新規に(point_rireki2等として)作り直してみようと思います! 上記の大きさのデータの場合、indexの設定等、他にも考慮すべき点などございますでしょうか...
iki

2018/03/13 01:56 編集

現在、 ・昨日までのpoint_rirekiテーブルのデータをinsertして、"no bigserial"の入ったpoint_rireki2テーブルの作成(noが主キーとなり、自動で連番する形となってます) ・user_idとdateにインデックスの追加 までは、実施することができました。 上記の状態で、新しいテーブルにて追記頂いたクエリを実行しているのですが、処理時間がかかってしまい、結果が出力できずといった状態です。。(エラーは出ず、クエリ実行中のステータスが続く形です) 他に処理を早くする方法等ご存知でしょうか。。
iki

2018/03/13 02:38

下記を実行したところ、 使用履歴のdateが(ユーザーごとに)最初の日付が必ず、新規となってしまっているのですがなぜでしょうか。(fuyo_pt_tjにデータが入っていることが多いのですが、データが入っていても最初の日付の行の部分は新規の扱いとなっております..)sumが働いていないということになるのだと思っているのですが、原因がわからないので、教えて頂きたいです。よろしくお願いいたします。 〈今回、実行した式〉 select *, case when exist_point>0 then '既存' else '新規' end as new_or_existing from ( select * ,(select sum(coalesce(fuyo_pt_tj,0)+coalesce(kan_pt_tj,0)+coalesce(kan_pt_kg,0)) from point_rireki2 where user_id=main.user_id and "date" >= main."date" - interval '3 months' and "date" < main."date" ) as exist_point from point_rireki2 main ) step1 order by user_id, date
sazi

2018/03/13 04:13

処理自体は自身を除き、自身の日付より過去3カ月以内という処理にしています。 新規・既存という名目からそう判断しているわけですが、自身の日付を含めて過去3カ月以内のポイントの有無ということであれば、where条件の部分を以下のように範囲を変更すればOKです。 "date" < main."date"→"date" <= main."date"
sazi

2018/03/13 04:35 編集

実際のところ、このテーブルに関して抽出するのはuser_id毎に取り出すのではありませんか? mainにwhere条件を追加しuser_idで限定すれば、結果は直ぐに返却されると思います。
iki

2018/03/13 05:00

>自身の日付を含めて過去3カ月以内のポイントの有無ということであれば >"date" < main."date"→"date" <= main."date" ありがとうございます!whereの日付の箇所でuser_idの初回の内容を規定していたんですね。ありがとうございました。 >実際のところ、このテーブルに関して抽出するのはuser_id毎に取り出すのではありませんか? 本当にありがとうございます!! 実は、先ほど社内でもご指摘頂きまして、まさにユーザー毎に取り出す形となります。。。 またもう一つのテーブルが、  ・施策キャンペーンのテーブルになりまして、そこに    施策ID,施策名,user_id,応募日などがあります。 そして、最終アウトプットが、施策ごとの新規/既存のユーザー数の抽出となったため、     施策の応募日を起点に、ポイント履歴のテーブルにおいて3カ月以内の使用有無で新規/既存を付け直す形へ変更することになりました。 そのため、結合に伴うフラグの付与については、別途質問を立てさせていただこうと思います。
sazi

2018/03/13 05:10

ちょっと気になった点が、 >・user_idとdateをそれぞれ indexに設定する それぞれではなく、以下のように複合インデックスである必要があります。 create index point_rireki_index01 on point_rireki(user_id,"date");
iki

2018/03/13 05:34

単一を2回行うわけではなく、複数で1行で行うんですね! ありがとうございます!
guest

0

「ポイント履歴」のテーブルに「新規ユーザー」「既存ユーザー」のフラグを
追加するんですか?

やるとしても「新規」か「既存」かは「ユーザー」側のテーブル
みたいなもののフィールドな気がするんですが。

エスパー回答になって申し訳ありませんがやろうとしていることは

『ユーザーIDのポイント履歴テーブルの最初の日付カラム』が
3ヶ月未満→既存
それ以上→新規
というような内容なのでは?

今の仕組みだと
・昨日初めてポイント履歴にユーザーIDができて、今日再度ポイント履歴にデータができる→既存ユーザー(3ヶ月以内のため)
・1年前に初めてポイント履歴にユーザーIDができ、半年前に再度ポイント履歴にデータができる→新規ユーザー(3ヶ月超のため)

みたいな風になってしまいますが…

言われていることはこんな感じでやろうと思えばできます。

sql

1select A.* 2 ,coalesce((select top 1 1 3 from ポイント履歴 as B 4 where B.ユーザーID=A.ユーザーID 5 and B.日付カラム between dateadd(month,-3,A.日付カラム) and A.日付カラム-1),0) as フラグ 6from ポイント履歴 as A

dateaddとかcoalesceはデータベースに合わせてください。

間違ってたのでSQL修正追記しました。

投稿2018/03/12 03:19

編集2018/03/12 04:10
sousuke

総合スコア3828

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

iki

2018/03/12 04:23

>『ユーザーIDのポイント履歴テーブルの最初の日付カラム』が >3ヶ月未満→既存 >それ以上→新規 >というような内容なのでは? ありがとうございます。頂いた点補足します。 ユーザーAさんの場合、下記のような形です。 date user point flag 20170101 A 100 新規 20170201 A 50 既存 20170515 A 200 新規 なので、おっしゃる通りだと思います。 頂いた内容で動かしてみようと思います。ありがとうございます。
iki

2018/03/12 04:24

>select top 1 1 top11とは、何を示しているのでしょうか??
sousuke

2018/03/12 04:48

DBがポスグレとわかる前だったので書いたものです。 データが3ヶ月以内に100件あろうが1件あろうが、フラグの結果は変わらないため1件見つけるだけでいいよという命令が「top 1」で取得する値が「1」なので 繋げて書くとそのようになります。 ポスグレではtopはlimit句になるんだったかな?
guest

0

・DB設計は大きくはマスタデータとトランザクションデータに分かれている。
・ユーザマスタのテーブルが別にある。
・トランザクションデータであるポイント履歴のテーブルの仕様を変更したい。
ってことですか?
それだと、新規ユーザって表現が微妙ですが累計ポイントをクリアするって意味で良いですか?
でしたら、新規フラグじゃなく獲得-使用ポイントのカラムと累計ポイントのカラムを持ったほうが良いと思います。
そうでなければテーブルの設計から見直すことをお勧めします。

投稿2018/03/12 03:27

hihijiji

総合スコア4150

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問