回答が長くなりますことをご了承下さい。。。

始めに

質問者様の現在の設計は、
maisumakunさんの回答の通り、
「EAV」アンチパターンとされる設計技法とされています。

DB設計などについては「SQLアンチパターン」という書籍にて、
そのアンチパターンに陥りやすい背景、
及びどのように改善すべきかまでまとめられているため、
当方としては是非ご一読してほしい書籍の一つです。

要件に対する設計是非について

「EAV」アンチパターンとはされていますが、
今回の要件のような場合では採用されるケースはしばしば見受けられます。

以下のような懸念が払拭できない場合は、
個人的には今回の設計方針が一番妥当とは考えます。

1. 機械情報(機械A、機械Bなど)の登録数は今後も増加していく
2. 機械情報に付随するパラメタ値は増減する恐れが高い
3. 機械情報に付随するパラメタのデータ型も今後増減する恐れがある（論理値、実数、文字以外が加わるなど）

上記の課題がある場合は、
テーブル数の上限の固定が困難なため、
今回のような汎用的テーブルの導入を推す根拠足るとは思えます。

ただしパラメタ値の検索条件の書き方次第で、
データ型のキャストが必要以上に発生することと、
データ集計などには向かないところが玉に瑕とかもしれません。

案２～案５への見解

案２について。
「機械ごとに定義情報を作っちゃえ！」ってことであれば、
あまりオススメできる手法ではありません。

理由は「要件に対する設計是非」にあげた懸念１番の問題があるためです。
特に機械情報の登録・修正・削除の頻度が高いと破綻しやすい手法です。

案３について。
情報によっては無駄なカラム情報を管理するだけになるので、
質問者様が言うように活かした設計ではないかなという印象ですね。

案４について。
データの実態自体は、XML, JSON, ハッシュオブジェクトシリアライズで保存ということなので、
それに起因して集計・運用時のノウハウは必要となってくる可能性は高いです。

うまいこと扱う自身がない場合は、
避けた方が無難かもしれませんね。

案５について。
当方はNoSQL系の経験が皆無のため、
こちらは有用なアドバイスができません・・・。

ちなみに、sm_ymさんの回答にあがっています、
カンマ区切りで１つのカラムに保持する方法は、
sm_ymさん自身もおっしゃっているよう破綻しやすいです。

「ジェイウォーク」アンチパターンしても有名なので、
まったくオススメは出来ません。

EAVを用いない設計方針として

「EAV」を回避しRDBらしく課題解決に無理に拘るのであれば、
一例としてあげるなら以下のようなデータモデリングとなる気がします。
下記のような設計とすると、
恐らくですが、新規テーブル定義追加リスクは発生しません。

ただし前提条件としては、
・今後データ型の増加は起こりえない

上記を満たす必要があり、

問題点としては、
・機械数・パラメタ数がわずかの場合必要以上のテーブル数となる
・単体では意味がなさないテーブルが多いため・別途ビューの作成が要求されるかもしれない

を許容する必要は出てきます。

以下は概念データモデル設計のほんの一例を記載します。
機械マスタ（ID, 機械名, ... , 登録日, 変更日)
機械別パラメータ（ID, 機械ID, 連番, パラメタ名, データ区分, 修正日）
 機械別文字列パラメータ (ID, パラメタ値)
 機械別数値パラメータ (ID, パラメタ値)
 機械別論理値パラメータ (ID, パラメタ値)

上記について簡単に説明します。
先ずは機械マスタですが、
こちらは機械共通の属性情報を管理します。
今後、機械一覧検索などが必要になった際に一覧表示する情報はここで管理するとよいでしょう。
尚、主キーはIDの想定です。

次に機械別パラメータですが、
こちらは各種パラメータ詳細テーブルの親テーブル、つまり汎化したものに当たります。
（※オブジェクト指向の抽象クラス・派生クラスをイメージするとよいかも）
こちらでは機械別パラメータの一覧だけを管理します。
尚、主キーはIDで、機械ID、連番に対して複合一意キーを付与する想定です。

ポイントは上記テーブルでは、

• パラメタごとのデータ区分を管理する
• パラメタの具体値までは管理させない

上記の２点となります。
パラメタごとの修正・変更日を管理したいなら、
このテーブルにカラムを設けると良いでしょう。

最後に各種パラメータ詳細テーブル（機械別文字列パラメータ）ですが、
こちらで各種パラメタの具体値を管理します。
この時点でデータ型は適切に管理されているため、
集計、条件比較に無駄なキャストが入り込む隙は与えません。
数値パラメータはnumeric型やnumber型などを利用すると、
整数・少数どちらでも管理可能です。

あとグラフ化なども行うとのことで、
要件次第ですが例えば全機械の電圧のみをグラフ表示するとかがあるなら、
数値パラメタテーブルに更に種別などをもたせて・・・、
など集計の切り口は詳細テーブル内でも与えられるのかなとは思われます。

尚、主キーはIDとなり親テーブルの機械別パラメータのIDと同一値が入る想定です。
データ整合性の観点から各種パラメータ詳細テーブル全てのIDには、
機械別パラメータのIDを参照する外部キー制約を定義すると尚良いでしょう。
（※設計段階で親子関係を明示する意図でも有用です）

ちなみに万一パラメータで保管すべきデータ型が増えたら、

• 各種パラメータ詳細テーブルの追加
• データ区分の追加

上記作業が必要となってきます。

蛇足

上記で紹介したテーブル構成だと、
検索時に何かと不便なので、
上記設計のような場合ではビューを作成することをオススメはします。

ついでなので以下にビューのイメージを記載しておきます。
注意点としてはビューで値を簡易的に一覧する場合は、
データ型を合わせる必要があることです。
(※要するにキャストが必要になるのが面倒です＾＾；)

実際に下記クエリは流してないので、エラーになる可能性大です。
あくまでイメージとして参考にして下さい。

CREATE VIEW "機械別パラメータ一覧ビュー" AS
SELECT
    m.ID AS "機械ID"
,   m."機械名" AS "機械名"
,   p."パラメタ名" AS "パラメタ名"
,   p."データ区分" AS "データ区分"
,   CASE p."データ区分"
      WHEN '1' THEN "文字列"
      WHEN '2' THEN "数値"
      WHEN '3' THEN "論理値"
      ELSE '‐'
    END AS "データ区分名称"
,   CASE p."データ区分"
      WHEN '1' THEN p_char."パラメタ値"
      WHEN '2' THEN CAST(p_num."パラメタ値" AS varchar)
      /* 
        下記の論理値は普通のキャストでTRUE、FALSEの文字列となるか怪しいので、
        多分直す必要があります。。。
       */
      WHEN '3' THEN CAST(p_bln."パラメタ値" AS varchar)
      ELSE ''
    END AS "パラメタ値"
,   p."修正日"
FROM
    "機械マスタ" m
    /* 以下テーブル群はパラメタ未登録の機械も表示要なら結合方法は「LEFT JOIN」へ */
    INNER JOIN "機械別パラメータ" p
      ON  m."ID" = p."機械ID"
    INNER JOIN "機械別文字列パラメータ" p_char
      ON  p.ID = p_char.ID
      AND p."データ区分" = '1'
    INNER JOIN "機械別数値パラメータ" p_num
      ON  p.ID = p_num.ID
      AND p."データ区分" = '2' 
    INNER JOIN "機械別論理値パラメータ" p_bln
      ON  p.ID = p_bln.ID
      AND p."データ区分" = '3'

また、上記だと結局パラメタ値は全て文字となってしまうので、
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。

追記

ただし今回のケースだと上記のようなRDBのルールに厳密に則って、
手間をかけて設計するメリットが薄い気がするので、
「EAV」の設計パターンの対策として上記のような手法がある、
程度に抑えておくだけで良いかと思います。

現在行われていらっしゃる手法1は、「Entity Attribute Value」という名前が付く程度にはよく行われる（けれども、RDBMSということを考えればそこまで筋が良いとは言い難い）手法です（Qiita）。

とはいえ、「RDBMSだけを使って」「一定の柔軟性を持たせる」場合には必要悪として採用されることもあります（WordPressにもこのような構造のテーブルがあります）。

データセットが数種類しかないのであれば、案2のように「機械ごとにテーブル作成」という手段も実用になるかなとは思います。

案1は割と良く目にします。
要件次第ではありますが、悪手ということもないと思います。
最善手かといわれれば、何とも言えないのですが。

案3もたまに見かけますが、RDBでやるのはどうかなぁと感じます。
レガシーな環境から移行したシステムでありがちっぽいです。

とあるシステムを案4で実装したことがあります。
JSONでデータを格納しました。
ただ、そのシステムはJSON部分で検索や集計をすることがほぼない前提だったため、案4を採用したのでした。
最近はRDBMSにもかかわらずJSONに対して検索できるものもある(新しめのSQL Serverはできたはず)ようなので、そういうRDBMSでしたら選択肢として案4もアリかもしれません。

お世話になります。あまり経験はありませんが、私も後学のため回答させていただきます。

まず、案に関する私の経験の度合いです。
案1 : 設計、実装、保守経験有
案2 : 未経験
案3 : 保守経験有
案4 : 未経験
案5 : NoSql等の運用経験はないのですが、よほどでない限りRDBでできることはRDBでする派です。
※ 案2に関しては、動的に一意となるテーブルを生成するということでしょうか。そういった経験はありませんが、とても興味深いです。

質問１．情報が少なくて恐縮ですが、「案１」を採用したのは正解だと思いますか？ 

私も同じ手法ですると思います。トランザクションデータを管理する上ではよく見ます。

質問２．現実的な案として下段以外のものはありますか？ 

1カラムにデータをカンマ等の区切り記号連結させ、文字列として格納しているテーブルも考えられると思います。(解析経験ありです。)

質問３．下段の案の中で、上記条件に対して「ありえない」と考えるものはありますか？ 

経験したことを踏まえると、案3でしょうか。予備カラムが無駄に思えて。。。

質問４．一般的にこういったもののデザインパターンはありますか？ 

質問1の回答と重複しますが、よく見かけます。

質問５．他、経験談や参考情報などありましたらご教示ください。 

質問2の回答の補足ですが、テーブルを解析した際、ドキュメントありき・レコードによってカンマ数が違う等、とても難解でした。。。
なので挙げてはいますが、よほどでない限り採用はしません。

データ量や、頻度、どのような集計・分析を行うかも考慮する必要があるかと思います。

個人的には、ログであること、それなりの量や頻度が見込まれることから、NoSQLを検討すると思います。
NoSQLでも、KVSタイプやドキュメント（JSONがそのまま入ったり）などがあり、集計ができないわけではありません。

http://www.slideshare.net/recruitcojp/rdbnosqlnosql

保守の観点でも、バリデーションができない点で１よりは４ですが、サイズが膨大になることを踏まえると、５になるかなといったところです。

案１と案３のいいとこ取りみたいな、
値の保持をvarcharだけにせず、
数字で持てるところはintegerやdouble precisionも活用して
入れ物を冗長に持たせる方が、
どうせSQLで合計値や平均値などを算出するでしょうから
文字列→数値変換を省く意味で使うかなと。
インデックスもかけられそうだし。

それに、測定データなら測定できなかったときの値という特殊な保持の仕方もあるので、
単にNULLやゼロではない別の意味をもたせたフラグも必要だったりしますので。

異なるスキーマを持ったログを同じテーブルに入れるのは誰も得をしません。
気温と電圧は比較が出来ないからです。
キーで分ける手間は開発にもDBサーバにもストレージに負荷をかけます。
このことから、現行の案１は今後問題になる可能性が高いです。

機械の種類ごとにテーブルを分けるのがRDBのやり方です。
この方法であれば、集計に問題が起こることはないと思います。

ただし、機械の種類が多すぎたり、非常に似た項目があるが機械毎に項目が少しずつ違う場合、
うまく管理出来ないということも考えられます。
その場合は、RDBは役に立ちません。苦手な事をさせても意味が無いと思います。

”日時・機械ID・明細”あたりのテーブルで、明細をプログラム側で集計しましょう。
データの表現はプログラム言語の方が豊かなので、管理もし易いと思います。

明細はXMLでもCSVでもどちらでも良いと思います。もちろん、案５でも良いです。
どちらにしろ集計は手間なので、DBの構造をいじる手間が減るだけマシにはあります。

案１．よく見ますね。可もなく不可もなく、選択肢としては悪くないと思います。
他の人間が保守・運用するとしてもそこまで抵抗なく触れるでしょうし。
RDBでやるのなら、私もこれかな、と。

案２．個人的には無くはない、という感じですが、採用には気が進みません。
システムの製造者=運用・保守担当者なら問題ないのですが、そうでない場合、
自動生成の特性上、どのテーブルが何の機械のテーブルなのか、後年に分かりにくくなりそうです。
破棄された機械のテーブルのケアとかも煩雑な気がしますね。

案３．RDBの必要ないですよね、多分。個人的には無しですかね。

案４．この組み合わせは遭遇したことが無いので、すいませんがノーコメント(汗

案５．現状で意見があまり出ていないこれに言及させてもらいます。
同じく、用途がログ解析の案件経験が有り、
その際はMongoDBというNoSQLのDBとpentahoというツールで導入しました。

問題は、pentahoに関しては日本語の情報は多くないので、使用者・開発者双方から毛嫌いされるケースがあるかもしれません。
（私の時はpentaho kettle solutionsという本で勉強しました）
NoSQLのDB経験者も人口は多くはないのかな...すいません、その辺は分かりません。

ただ、そんな感じできちんと知識が無いと開発しずらいことから、
プロジェクトメンバー全員にRDBに比べればマイナーな知識が要求されます。
そのハードルさえ超えれれば、この手のDWH解析寄りの案件には非常にマッチするかと思います。

KEYに格納されているデータの種類はどれくらいあるのでしょう？あと機械の種類はどれくらいでしょう？
DWHの世界ではカラム数が数百あるテーブル定義も珍しくありません。
あと扱っているデータは蓄積していくもののようですからテーブル定義の変更はカラムの追加だけのような気がします。

先の種類の数によりますが、今後もずっとデータを記録していくなら、私なら一つのテーブルにするか機械の種類毎のテーブルにしますね。それからパフォーマンスとバックアップ単位を考えてデータベースを拠点毎や一定期間で切り分けます。

更にデータ量が億単位になる点から、RDBでの処理範囲を超えるかもとも考えます。

ビッグデータの分析の世界ではRDBではなくTSVファイル形式でデータを保存しておいて、それをテーブルに見立てて分析をかけることも珍しくありません。Apache Hadoop とかはその典型的なものでしょう。
Hadoopの機能をサービスとして提供してくれるAWSのEMRと呼ばれるプロダクトも便利です。
テラバイト単位のデータも扱ってくれるから良いですよ。

とある情報を管理する製品が「GUIから定義を追加する事で各情報に任意のデータも追加できます」と言っていたので買ってみたら案3だった時があります。データは全て文字列型で、その他1、その他2…とたくさん用意されているだけで、

• このデータは真偽値で→その他1で"TRUE"、"FALSE"という文字列で管理します！
• このデータは整数値で→その他2で"0"、"1".. "100"という文字列で管理します！

という感じで、そしてVARCHAR(255)だし、255文字越える文字列データはどうするんだと聞いたら、分割して入れてくれとかふざけたこと抜かしました。二度とあの製品は買いません。

愚痴はここまでとして、サーバーの各情報(ディスク容量とか登録ユーザー数とか、メール総受信数とか色々)を集めてDBで管理するものを作った時、案5を採用しました。採用したDBはMongoDBです。1データの読み込みなら、WebからJSON受け取ってブラウザ側で処理するって方法だったので、JSONにしやすいMongoDBにしたという理由もありますが、サーバによってとりたい情報がバラバラだし、今後も増えていきそうだったのでNoSQLであるMongoDBにしたというのがあります。まだ、集めた過去の情報を閲覧できるだけで、本格的な分析とかの部分は作ってないので、集計とかするときはどんな感じと言われても、なんとも言えないのが現状ですが。

MongoDBの何が良かったというと、スキーマレスな所です。JSONっぽいBSONというものなので、階層化されたデータをそのまま扱えますし、一つ一つテーブル定義をしていく必要が無かったのは楽でした。ただ、ちゃんと最初にどういうデータ構造にするかを詰めておかないと、やっぱこれも！とかなってコード部分の方に出戻りがでるので、そこら辺はきちんとしたほうがいいようです。

もし、RDBMSという縛りがあるなら、Panzer_vorさんの方法をオススメします。任意のデータを追加できる系の結構メジャーなOSSではそのような構造を取っているようです(前に何かで見たんですが、何だったかまでは…たしか、uPortalだったかな？)。市販の製品は本当にできが悪いものが多くありますので、参考にしない方が良いと思います。

MariaDBを使ってるならDynamic Columnを検討するのも手かもしれないです (使ったこはないです)。

https://mariadb.com/kb/en/mariadb/dynamic-columns/