Abstract
Our understanding of COVID-19 vaccinations and their impact on health and mortality has evolved substantially since the first vaccine rollouts. Published reports from the original randomized phase 3 trials concluded that the COVID-19 mRNA vaccines could greatly reduce COVID-19 symptoms.
In the interim, problems with the methods, execution, and reporting of these pivotal trials have emerged. Re-analysis of the Pfizer trial data identified statistically significant increases in serious adverse events (SAEs) in the vaccine group. Numerous SAEs were identified following the Emergency Use Authorization (EUA), including death, cancer, cardiac events, and various autoimmune, hematological, reproductive, and neurological disorders. Furthermore, these products never underwent adequate safety and toxicological testing in accordance with previously established scientific standards.
Among the other major topics addressed in this narrative review are the published analyses of serious harms to humans, quality control issues and process-related impurities, mechanisms underlying adverse events (AEs), the immunologic basis for vaccine inefficacy, and concerning mortality trends based on the registrational trial data. The risk-benefit imbalance substantiated by the evidence to date contraindicates further booster injections and suggests that, at a minimum, the mRNA injections should be removed from the childhood immunization program until proper safety and toxicological studies are conducted.
Federal agency approval of the COVID-19 mRNA vaccines on a blanket-coverage population-wide basis had no support from an honest assessment of all relevant registrational data and commensurate consideration of risks versus benefits. Given the extensive, well-documented SAEs and unacceptably high harm-to-reward ratio, we urge governments to endorse a global moratorium on the modified mRNA products until all relevant questions pertaining to causality, residual DNA, and aberrant protein production are answered.
⇧ 正直、前例のないワクチンということで、人体に及ぼす影響についての評価とかどうしているのか気になりますな。
気になるのは、上記の記事の著者の方々の研究分野ですかね。
mRNAワクチンに対して精通した有識者なのか。
そもそも、分析に耐え得るような正確なデータって存在しているんだろうか...
一番怖いのは、データが改竄されてるパターンよね...
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ とありますからな...
mRNAワクチンについては、公開されているデータを信頼するしかないんですが...
意図的に不都合なデータを隠蔽されてたりしても、アウトなんだけどね...
mRNAワクチンに関わる企業には、
という思想であって欲しいですな...
VerticaでテーブルのDDLのエクスポートが可能だが、テーブル毎にファイルを分けれないっぽい...
例の如く、
- Gitリポジトリで管理しているもの
- 本番環境で利用しているもの
とで、テーブルの構造が違ってきてしまって、DDL（テーブル作成のSQL）の差分を確かめたくて、VerticaのDDL（テーブル作成のSQL）を出力する方法を探していたところ、
⇧ 同じようなお悩みに遭遇された先駆者の方がおられました。
で、嫌な予感が...
全てのテーブルのDDLを1つのファイルに出力していらっしゃる...
自分の思い描いていたのは、例えば100個テーブルがあったら、100個のファイルで出力して欲しかったんですな。
そうすれば、WinMergeとかでサクッと差分比較できると思うんだけど、Verticaの仕様がだいぶイケて無さそう...
ドキュメントを見ても、
⇧ 出力を良しなにしてくれないっぽい...残念過ぎる...
ちなみに、
⇧ データベースを指定する時は、スキーマも付けないとエラーになることがあるので、
'データベース.スキーマ'
⇧ としておいた方が無難かなぁ...
と言うか、データベースの指定って言葉に騙されてハマったから...
スキーマ.テーブルのようにテーブルの前にスキーマを付けるってのは、Oracle Databaseとかで見たことあるけど、データベース.スキーマってのは初めて遭遇しましたわ...
とりあえず、ChatGPTに聞いてみたところ、
はい、Verticaのように、database.schemaの形式でアクセスするデータベースは他にもいくつかあります。以下はそのいくつかの例です：
- Amazon Redshift: Amazon Redshiftは、Verticaと同様に、database.schemaの形式でアクセスできるクラウドベースのデータウェアハウスサービスです。
- Snowflake: Snowflakeは、クラウドベースのデータウェアハウスプラットフォームで、Verticaと同様に、database.schemaの形式でアクセスできます。
- Google BigQuery: Google BigQueryは、Google Cloud Platform上で提供されるサーバーレスのビッグデータクエリサービスであり、データセットがproject.datasetの形式で識別されます。
- Microsoft Azure Synapse Analytics (formerly SQL Data Warehouse): Azure Synapse Analyticsは、クラウドベースのデータウェアハウスサービスであり、Verticaと同様に、database.schemaの形式でアクセスできます。
⇧ 上記のようなサービスが列挙されましたと。
大量のデータを扱うようなサービスだと、Verticaのようなデータベースへのアクセスの仕方が一般的なんですかね？
スキーマで複数のアプリケーションで利用するテーブルが混在している場合、お目当てのテーブルだけ抽出とかも難しいし、痒い所に手が届かない、何とも使い勝手は芳しくないのだけど、これといって、代替案が無さそうなので、茨の道を進むしか無さそう...
「A5:SQL Mk-2」とかGUIツールでVerticaにアクセスできるなら、「A5:SQL Mk-2」のエクスポート機能を使いたいのだけど、
⇧ 流石にサポート外っぽいですね。
Verticaの代替として利用できそうなものが無いのかしら、ということで、そもそもVerticaは何ぞということを、Wikipediaさんに聞いてみたけども、
列指向データベース管理システムは、データベース管理システム (DBMS) の内部構造において、列のデータをひとまとまりにして取り出すときに効率的であるように設計されたものである。これはデータウェアハウスや図書館のカタログのように、大量の類似のデータ項目に対し集計が行われるものに対して有用である。
列指向データベース管理システムは、一般的に「カラムナデータベース」 (Columnar Database) とも呼ばれる。
⇧「列指向データベース」ということで、通常のWebアプリケーションで一般的な「RDBMS（Relational DataBase Management System）」と趣が異なりますと。
NoSQLのカラム指向データモデルとの差異
大規模データを対象としたNoSQL型DBMSの中には「カラム指向型」と呼ばれるものがある。しかしここでいうカラム指向（列指向）とは、DBMSの利用者から見えるデータモデルを表しており、DBMS内部のデータ格納方式を表しているわけではない。これらは、本項で扱う列指向DBMSとは利点が全く異なるので注意が必要だ。
NoSQLのカラム指向データモデルは、非定型の大規模データを格納することを主な目的としており、行ごとに任意の名前のカラム（列）を無数に（時には1行に数百万カラム）格納できる。それぞれのカラムは、行ごとにカラム名の辞書順によってソートされ、1回のクエリで、指定した1行に属する全てのカラムを取り出したり、指定した1行に属する指定した範囲のカラムだけを取り出したりできる。少数の行に対する多くの列の取得に適しており、大量の行に対する少数の列の集約処理には適さない。このようなDBMSには、Apache HBase、Apache Cassandraなどがある。
一方、NoSQLではないが、大規模データを対象にSQL形式の分散クエリを実現するソフトウェアでは、列指向DBMSと同様のデータ格納方式を採用し、同じ利点を持つ。
このようなソフトウェアは分散SQLクエリエンジンと呼ばれ、Google Dremel/BigQuery、Amazon Redshift、 Apache Hadoop上で動作するCloudera Impalaなどがある。
⇧ 参照系の処理に強く、更新系の処理が苦手そうなので、データ分析とかの用途に向いているってことですかね？
決済処理のように更新が頻繁に行われるような機能が多いシステムには向いていないってことですかね。
Wikipediaの情報を見る限りだと、Verticaの代わりに利用できそうなものが無さそうな感じなんかな...
Google Cloud（【旧】GCP：Google Cloud Platform）のBigQueryとか使ってみたいけど、
⇧ 怖すぎて気軽に利用できない...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
