質問編集履歴
7
URLにリンクをつけました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
以下のようなサイトでも言われているように、CRUDのUとDを利用せずデータをログのように扱う方法は関連するデータ（特に履歴）が失われないために好感が持てました。
|
|
4
4
|
|
|
5
|
-
http://tanakakoichi9230.hatenablog.com/entry/6715376804
|
|
5
|
+
[http://tanakakoichi9230.hatenablog.com/entry/6715376804](http://tanakakoichi9230.hatenablog.com/entry/6715376804)
|
|
6
|
-
http://qiita.com/Jxck_/items/156d0a231c6968f2a474
|
|
6
|
+
[http://qiita.com/Jxck_/items/156d0a231c6968f2a474](http://qiita.com/Jxck_/items/156d0a231c6968f2a474)
|
|
7
|
-
http://mike-neck.hatenadiary.com/entry/2015/03/24/231422
|
|
7
|
+
[http://mike-neck.hatenadiary.com/entry/2015/03/24/231422](http://mike-neck.hatenadiary.com/entry/2015/03/24/231422)
|
|
8
8
|
|
|
9
9
|
現在MySQLを利用してウェブサービスを作成しようと考えているのですが、実際にUとDを利用しないDB設計をするにはどうすれば良いのかというところでつまづいてしまいました。
|
|
10
10
|
|
6
MySQLタグを削除
title
CHANGED
|
File without changes
|
body
CHANGED
|
File without changes
|
5
タグを追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
File without changes
|
4
不要な変数名を省略
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -31,7 +31,7 @@
|
|
|
31
31
|
アクションログ用テーブル（action_id, target_db, target_column, value, created）を作成し全てのデータ操作をログとして残し、ログデータが追加された場合にトリガーを利用して最新データ参照用テーブルをupdateする。（valueの型をどうするべきかは不明。おそらくTEXT型）
|
|
32
32
|
|
|
33
33
|
⑤
|
|
34
|
-
アクションログはRDBではなくログデータとしてディスクに書き込み、RDBは通常通りCRUDする。また、アクションログを書き込むプログラムをモジュール化し、```dataModule.set(
|
|
34
|
+
アクションログはRDBではなくログデータとしてディスクに書き込み、RDBは通常通りCRUDする。また、アクションログを書き込むプログラムをモジュール化し、```dataModule.set(id, name, value);```などの関数を利用してデータを書き込む際には自動的にログファイルとRDBの両方が書き換えられるようにする。（そのモジュールにログファイルからDBを作成できる機能などあると良いかも）
|
|
35
35
|
|
|
36
36
|
①は無駄に容量を食うのであまり良くないと思っています。②に関しては「NULLは使うな」と良く言われてるのでそれがひっかかります。あとデータを取得する際に複雑なクエリを発行することになりそうです。③はNULL利用が不安なことは変わりありませんが、データ書き込みと取得で異なるテーブルを使うので複雑クエリ問題は解消しそうです。④この方法が良いんじゃないかと個人的に思っていたのですが、value型をどうするかという問題が残っています。またtext型を利用した場合、大量のログがtext型でinsertされることを考えると少し不安になります（全く問題ないのかもしれませんが）⑤については最終的にこれが一番良いのではないか？と思って現在検討している方法になります。しかしこれだと今までずっと"CRUD is Dead"の考え方できたのに、結局CRUDでDB操作しちゃってますね（汗。しかしログファイルを取ることで、何かあった時にはログファイルからDBを復元したり、調査が必要になった時にログファイルを確認したりできるのでCRUDのUとDは使ってますけどUとDを使わなかった時のメリットは得ることができているといった感じでしょうか。
|
|
37
37
|
|
3
わかりにくい文言を修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -33,7 +33,7 @@
|
|
|
33
33
|
⑤
|
|
34
34
|
アクションログはRDBではなくログデータとしてディスクに書き込み、RDBは通常通りCRUDする。また、アクションログを書き込むプログラムをモジュール化し、```dataModule.set(user_id, name, value);```などの関数を利用してデータを書き込む際には自動的にログファイルとRDBの両方が書き換えられるようにする。（そのモジュールにログファイルからDBを作成できる機能などあると良いかも）
|
|
35
35
|
|
|
36
|
-
①は無駄に容量を食うのであまり良くないと思っています。②に関しては「NULLは使うな」と良く言われてるのでそれがひっかかります。あとデータを取得する際に複雑なクエリを発行することになりそうです。③はNULL利用が不安なことは変わりありませんが、データ書き込みと取得で異なるテーブルを使うので複雑クエリ問題は解消しそうです。④この方法が良いんじゃないかと個人的に思っていたのですが、value型をどうするかという問題が残っています。
|
|
36
|
+
①は無駄に容量を食うのであまり良くないと思っています。②に関しては「NULLは使うな」と良く言われてるのでそれがひっかかります。あとデータを取得する際に複雑なクエリを発行することになりそうです。③はNULL利用が不安なことは変わりありませんが、データ書き込みと取得で異なるテーブルを使うので複雑クエリ問題は解消しそうです。④この方法が良いんじゃないかと個人的に思っていたのですが、value型をどうするかという問題が残っています。またtext型を利用した場合、大量のログがtext型でinsertされることを考えると少し不安になります（全く問題ないのかもしれませんが）⑤については最終的にこれが一番良いのではないか？と思って現在検討している方法になります。しかしこれだと今までずっと"CRUD is Dead"の考え方できたのに、結局CRUDでDB操作しちゃってますね（汗。しかしログファイルを取ることで、何かあった時にはログファイルからDBを復元したり、調査が必要になった時にログファイルを確認したりできるのでCRUDのUとDは使ってますけどUとDを使わなかった時のメリットは得ることができているといった感じでしょうか。
|
|
37
37
|
|
|
38
38
|
このように幾つかの方法を考えたのですが、そもそも一般的なベストプラクティスがあるのではないか？と思いましたので是非そういった参考にできるサイトや、俺だったらこうするという意見がございましたら教えていただきたいと思っています。
|
|
39
39
|
|
2
読みにくい文言を修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -31,9 +31,9 @@
|
|
|
31
31
|
アクションログ用テーブル（action_id, target_db, target_column, value, created）を作成し全てのデータ操作をログとして残し、ログデータが追加された場合にトリガーを利用して最新データ参照用テーブルをupdateする。（valueの型をどうするべきかは不明。おそらくTEXT型）
|
|
32
32
|
|
|
33
33
|
⑤
|
|
34
|
-
アクションログはログデータとして
|
|
34
|
+
アクションログはRDBではなくログデータとしてディスクに書き込み、RDBは通常通りCRUDする。また、アクションログを書き込むプログラムをモジュール化し、```dataModule.set(user_id, name, value);```などの関数を利用してデータを書き込む際には自動的にログファイルとRDBの両方が書き換えられるようにする。（そのモジュールにログファイルからDBを作成できる機能などあると良いかも）
|
|
35
35
|
|
|
36
|
-
①は無駄に容量を食うのであまり良くないと思っています。②に関しては「NULLは使うな」と良く言われてるのでそれがひっかかります。あとデータを取得する際に複雑なクエリを発行することになりそうです。③はNULL利用が不安なことは変わりありませんが、データ書き込みと取得で異なるテーブルを使うので複雑クエリ問題は解消しそうです。④この方法が良いんじゃないかと個人的に思っていたのですが、value型をどうするかという問題が残っています。（text型を利用して大量のログがinsertされることを考えると不安になります）⑤については最終的にこれが一番良いのではないか？と思って現在検討している方法になります。
|
|
36
|
+
①は無駄に容量を食うのであまり良くないと思っています。②に関しては「NULLは使うな」と良く言われてるのでそれがひっかかります。あとデータを取得する際に複雑なクエリを発行することになりそうです。③はNULL利用が不安なことは変わりありませんが、データ書き込みと取得で異なるテーブルを使うので複雑クエリ問題は解消しそうです。④この方法が良いんじゃないかと個人的に思っていたのですが、value型をどうするかという問題が残っています。（text型を利用して大量のログがinsertされることを考えると不安になります）⑤については最終的にこれが一番良いのではないか？と思って現在検討している方法になります。しかしこれだと今までずっと"CRUD is Dead"の考え方できたのに、結局CRUDでDB操作しちゃってますね（汗。しかしログファイルを取ることで、何かあった時にはログファイルからDBを復元したり、調査が必要になった時にログファイルを確認したりできるのでCRUDのUとDは使ってますけどUとDを使わなかった時のメリットは得ることができているといった感じでしょうか。
|
|
37
37
|
|
|
38
38
|
このように幾つかの方法を考えたのですが、そもそも一般的なベストプラクティスがあるのではないか？と思いましたので是非そういった参考にできるサイトや、俺だったらこうするという意見がございましたら教えていただきたいと思っています。
|
|
39
39
|
|
1
誤字の修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
"CRUD is Dead"なんて言われてる方もいらっしゃるようでCRUDのUとDを禁止する流れが存在するようです。
|
|
2
2
|
|
|
3
|
-
以下のようなサイトでも言われているように、
|
|
3
|
+
以下のようなサイトでも言われているように、CRUDのUとDを利用せずデータをログのように扱う方法は関連するデータ（特に履歴）が失われないために好感が持てました。
|
|
4
4
|
|
|
5
5
|
http://tanakakoichi9230.hatenablog.com/entry/6715376804
|
|
6
6
|
http://qiita.com/Jxck_/items/156d0a231c6968f2a474
|