テーブルの継続的な作成と削除は、アーキテクチャ上の欠陥の兆候ですか？
最近、私は開発者と話し合いをしました。プログラム開発中、彼らは定期的にテーブルと列を定期的に作成および削除する一方で、新機能に取り組み、アジャイル開発プロセスを使用する場合はこれは正常であると言って正当化しました。
私のバックグラウンドのほとんどはウォーターフォール開発環境にあるので、これがアジャイル開発で実際に適切であると考えられるのか、それともプログラムアーキテクチャまたはアジャイルプロセスの後続のいずれかによる根本的な問題の兆候であるのかと思います。
「アジャイル」がよく考えられていない、混沌とした、急いでいる、そして自分のパンツの代名詞になっていることは、私にはますます明白になっています。そして、私が理解しているように、これらのいずれもアジャイルアプローチと互換性がありません。
効果的で再現性のあるアジャイルプロセスを持つことは簡単ではありません。優れた製品につながる可能性があっても、本質的に実行する作業の総量が減るとは思いません。
データベースを「リファクタリング」する時間がないと彼らが言ったなら、おそらくデータベースのバージョン管理と移行をセットアップする時間もないでしょう。彼らはおそらく、そのための一連の機能テストを作成するのに時間をかけていません。これらすべては、成功に向けた強固なアジャイルプロセスを考えるときに私が考えることです。
結局、アジャイルは単なる言葉です。あなたが日々行っていることは、あなたが成功するかどうかを決定します。
設計の進展に伴ってテーブルを作成および削除することは珍しいことではありませんが、データベースがこれらのテーブルをすべて実際に使用していることを確認するために、いくつかのクリーンアップが行われる場合があります。
はい、アジャイルはすべてリファクタリングに関するものですが、システムが大きすぎてリファクタリングできないと彼らが言っている場合、彼らはアジャイルの実行をやめ、現在はカウボーイプログラミングにすぎません。開発チームはそれと呼ばれることを嫌いますが、それは彼らがやっていることです。動くものは何でも射程に乗ってください。
DBAがお手伝いします。開発とアジャイル開発を理解しているDBAを確保してください。あなたの開発チームは刑務所に投げ込まれるのではなく、拘束される必要があります。
一般に、プログラミングとデータベース管理が厳密に分離されていないプロセスでは、新しいテーブルの作成と新しい列の追加は非常に正常です。新しい機能は、どこかに行く必要がある新しいデータを作成する場合があります。それを避けるために厳格に試してみてください inner-platform model になります。
適切に作成されたソフトウェアは、これらの新しいデータベースオブジェクトにほとんど気付かないため、一部のテーブルに新しい列があるだけでは、何も壊れません。
一方、定期的に列やテーブルを削除することは疑わしいです。新しい機能ではテーブルを削除する必要がないので、これは完全に無計画で働いている人々の兆候である可能性があります。
データベースのバージョン管理と移行を簡単に行うことができ、変更を加えても問題が発生しないことを証明するテストがある場合は、おそらく非常に機敏なプロセスが実行されています。
コメントに照らして-一般的にこれらの影響に対して、アジャイルであると正当化するカウボーイの束です-悲鳴を上げます。速い。そして、できる限りのことをthedailywtf.comに投稿して、私たち全員が恐怖を楽しむことができるようにしてください。
StackExchangeでのほとんどの回答と同様に、返信は「依存する」はずです。アジャイル開発では、実装中に要件と仕様が発見されます。
ただし、アジャイル開発では、リレーショナルモデルが適切に正規化されている場合、新しい属性をリレーションに追加する必要はほとんどありません。新しいエンティティは通常、古いものを参照する必要がありますgiven適切なモデル。
ほとんどの開発者は、時間の制約、遅延、無能、またはクエリの複雑さのために、DBを正規化しません。再正規化には、リスク要因を生成する既存のデータの転送、DAOの変更などが必要です。
あなたの質問に答えるために、いいえ、それはアジャイルプロセスでは普通ではありません。
アジャイル態度から派生する可能性があるのはseemは、アジャイルの短い反復設計/開発/テストサイクル、および既知の要件を満たす軽量のソリューションに重点を置いていますが、構造化されているためです。最小限の変更で新しい要件を満たすことができます。これらの2つのことを考えると、開発者は何が起こるかわからないが、彼の変更が元に戻せないような方法でDBに影響を与えるべきではなく、単にスキーマ内のスキーマに必要な変更を加えるだけだと言うかもしれません「最も軽い」方法が可能であり、その後、いくつかの「軽い」変更のセットがより永続的で安定したものにリファクタリングされます。
そうは言っても、私はまだアジャイルの理論と方法論に加入している開発者とは協力しておらず、スキーマ内のテーブルを定期的に作成および削除することが何らかの理由で必要であると考えていました。アジャイルは、平手打ちやボルトオンという意味ではありません。特定のレコードに属するデータの新しいフィールドを追加する必要があるストーリーが提供された場合は、そのフィールドをテーブルに追加します。その変更が何かを壊す場合は、理由を理解し、必要に応じて他の変更を行います（クエリ対象のDBに列を追加することによって壊れる可能性のあることは非常に少ないと考えることができます。この種の変更で壊れる場合は、より大きな問題があります）。通常、リファクタリングはコードに限定されています。スキーマの変更は通常、コードの変更よりも複雑なプロセスであるため、スキーマの変更を行う必要がある場合は、通常、より慎重に行い、少なくともプロジェクトの将来の方向性の知識に注意を払います。データベースの一部またはすべてを再構築する必要があることは、設計の根本的な失敗を示しています。アジャイルであることは、プログラムとデータ構造を有機的に構築するときに従うべき基本的なアーキテクチャと設計ルールの「マスタープラン」がないことを意味しません。
さて、アジャイルでは、今あなたが「知っている」ことが後で学ぶことと矛盾する場合があります。システムにすべての人のアドレスが必要であるという要件があるとします。これは1対1の関係であり、ほとんどの場合にデータが必要になるため、住所フィールドをPersonテーブルに追加するだけです。 1週間後、個人が複数のアドレスを持つことができるという要件を受け取ります。これで1：Nの関係になりました。適切にモデル化するには、以前の変更を元に戻して、フィールドを新しいアドレステーブルに分割する必要があります。これは、特に上級開発者の間では、日常的なことではありません。経験豊富な開発者は、Personにアドレスがあることを確認し、これらを概念的に分離していると見なし、PersonテーブルとAddressテーブルを作成して、PersonをAddressIDへのFK参照でリンクします。このようなスキーマは、関係の性質が変わった場合に簡単に変更できます。 「ワイド」データテーブル全体を作成または削除しなくても、個人と住所の関係を1：1から1：NからN：Nにかなり簡単に変更できます。
アジャイルで作業する場合、事前の設計にはそれほど重点が置かれていないため、最初のリリースでは、これが大きな問題であるとは思いません。
私が見たことのない700のテーブルがあるシステムについてコメントするのは難しいです。すべてのテーブルが必要になるかもしれませんが、データベースが十分に管理されていない場合もあります。
アジャイルのもとでも、大きなシステムの場合、スキーマを担当する誰か/チームがまだいるのはごく一般的です。
彼らが頻繁にそのような変更を行っている場合-特にライブアプリケーションでテーブルと列を削除する場合-これは経験不足の兆候のようです。彼らが従うと主張しているプロセスとは何の関係もありません。 「アジャイル」は座っていないわけではなく、コードを書き始める前に、格納する必要があるデータとその関連性についてthinkについて説明します。彼らが最初の構造の10〜20％以上を変更していることを発見した場合、それは私が彼らが物事を熟考していないか、要件の分析とデータベースの設計に多くの経験がないためのインジケーターであり、彼らは単にそれの多くは最初は間違っています。
あなたのチームは確かに単にカウボーイコーディングであるように聞こえますが、コードのリファクタリングに本当に問題はないはずですORデータベース。作業を失うことはなく、新しく学習した現実に適応しています。
チームが必要とするのは、変更を試し、いくつかのテストを行い、ユーザーから跳ね返して、意味があるかどうかを判断するためのサンドボックスです。その時点で、適切な回帰テストを使用して、意味のある変更をスキーマに統合することは問題ありません。
アジャイルはコーディングについてであり、データベースはコーディングではありません。データベースの変更は、家の改造のように扱う必要があります。人々はどういうわけか、アジャイルとは行動が今すぐ計画を立てることを信じていますが、これは完全に真実ではありません。アジャイルな方法でも、特にデータベースの設計と同じくらい重要なものについては、計画に時間をかける必要があります。
私の最後の仕事はこのようなチームでした。アジャイルプロセスを使用する場合、要件が変更されます。変更によって、既存のエンティティに新しい属性が必要になり、既存のテーブルに新しい列ができる場合や、新しいエンティティ全体が必要になるため、既存のテーブルとの関係を持つ新しいテーブルが必要になる場合があります。これらの種類の変更は領域に付属しており、スキーマに触れたくないという理由だけで無視することはできません。成功は、あるデータベースバージョンから次の適切な単体テストに移行するときにデータの整合性を維持することによって決定されます。
スキーマに不必要な変更を加えないようにしてください。たとえば、機能で新しいテーブルの作成が必要な場合は、テーブルをチェックインしてテスト環境にロールアウトする前に、そのテーブルの定義に問題がないことを確認してください。データの移行後にデータベーススキーマへの変更を取り消さなければならないのは、大変な作業です。