質問編集履歴

2

表記の修正

2018/10/03 04:01

投稿

namnium1125
namnium1125

スコア2043

test CHANGED
File without changes
test CHANGED
@@ -66,7 +66,9 @@
66
66
 
67
67
 
68
68
 
69
+ ~~これで大体1000MBぐらいでした。~~(1GBもあるわけない(^ ^; 表記を誤りました)
70
+
69
- これで大体1000MBぐらいでした。
71
+ これで大体1000Bぐらいでした。
70
72
 
71
73
 
72
74
 

1

追記いたしました。。引き続きよろしくお願いします。

2018/10/03 04:01

投稿

namnium1125
namnium1125

スコア2043

test CHANGED
File without changes
test CHANGED
@@ -19,3 +19,59 @@
19
19
 
20
20
 
21
21
  雑な質問ですみません...よろしくお願いします。m(_ _)m
22
+
23
+
24
+
25
+ # 追記
26
+
27
+
28
+
29
+ ご指摘ありがとうございます。リストの構造はこんな感じです
30
+
31
+
32
+
33
+ ```python
34
+
35
+ [
36
+
37
+ {
38
+
39
+ data1: "文字列データ1(半角40字程)",
40
+
41
+ data2: "文字列データ2(半角160字程)",
42
+
43
+ data3: "日付データ(例: 2018-10-02T23:02:37.000Z)",
44
+
45
+ data4: {
46
+
47
+ data3_1: "10字程度の文字列",
48
+
49
+ data3_2: "長さ不定の文字列"
50
+
51
+ },
52
+
53
+ },
54
+
55
+ {
56
+
57
+ # 上記と同様
58
+
59
+ },
60
+
61
+ # ...これぐらいのものが100個で一つのリストです。
62
+
63
+ ]
64
+
65
+ ```
66
+
67
+
68
+
69
+ これで大体1000MBぐらいでした。
70
+
71
+
72
+
73
+ 関数がリストを保持しなければならない理由は、繰り返しとなってしまいますが、「スクレイピングで連続でデータを取っているために途中でデータベースに保存といった処理を介入させるのが難しい」ことと、それに付随して「関数にデータベース保存の処理を入れるとなるとすべて書き直しとなり、それぐらいならば現状維持でよい」というのがあります。要は面倒だからです。Django以外で使用する可能性はないとはいえ、関数中にDjangoによるハードコードを介入させたくないというのもあります。
74
+
75
+
76
+
77
+ ...ただ書いてて思いついたのは、イテレータにするという手はあるかなとは思いました。データベースに保存する処理を待たなければなりませんが、個々のデータに関係性はないため、書き直しはできるかもしれません。ちょっと試してみようと思っています。