以下のクエリを使用して新しいレコードをテーブルに追加すると (不明)、新しいレコードが最初のテーブルに追加されました。table の最後に新しいレコードを追加したい。
この私のコード:
begin
insert into TBLCrowler (Url,Title,ParentId,HasData) values (@Url,@Title,@ParentId,@HasData)
end
以下のクエリを使用して新しいレコードをテーブルに追加すると (不明)、新しいレコードが最初のテーブルに追加されました。table の最後に新しいレコードを追加したい。
この私のコード:
begin
insert into TBLCrowler (Url,Title,ParentId,HasData) values (@Url,@Title,@ParentId,@HasData)
end
select top 1 CatId, Title, ParentId, Url, CrawlerCheck from TBLCrowler where CatId=(Select min(CatId) from TBLCrowler where CrawlerCheck=1)
update TBLCrowler set CrawlerCheck=2 , HasData=2
where CatId=(Select min(CatId) from TBLCrowler where CrawlerCheck=1)
さて、もう一度違反に。リレーショナル データベースを使用しています。これはワークシートではなく、Word 文書内のセルの長方形配列ではありません。その力は、可能な限り最も効率的な方法でレコードを保存および取得できることに依存しています。
順序付けは、DBMS が自由に無視でき、いずれにせよ変更される可能性があるインデックスによって暗示されるか、または order by ステートメントによって明示的に要求されます。
テーブルに追加された時点で並べ替えたい場合は、created_at 列を追加し、挿入時にデータを入力します。
次に、そこから選択するOrder By Created_At
と、選択ステートメントに追加されます。
順序付けを「高速」にしたい場合は、Created_At 列にインデックスを追加します。これにより、DBMS は、フル パス ソートのコストを回避するために、インデックスの使用を大胆に試みます。
一歩下がって、DBMS をどのように作成するかについて少し考えてみてください。あなたの暗黙の秩序のコストはどうなるでしょうか。「最後の」テーブルの「最後の」レコード以外への変更は、「その後」のすべてのテーブルのすべてのレコードをディスクに再書き込みすることを意味します。挿入はさらに悪く、削除も同様に悪く、それは、異なるレコードが異なる量のスペースを占有することを考慮していません。
見つけたら最初と最後にゴミ箱に捨ててください...