CREATE TABLE [dbo].[Table_5](
[Date] datetime NOT NULL,
[ID] timestamp NOT NULL,
[Name] [varchar](50) NOT NULL,
CONSTRAINT [PK_Table_5] PRIMARY KEY CLUSTERED
(
[Date],[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Table_5] ADD CONSTRAINT [DF_Table_5_ID] DEFAULT (current_timestamp) FOR [Date]
GO
INSERT INTO Table_5 (Name)
SELECT TOP(5) 'TEST' + CAST(ROW_NUMBER() OVER(ORDER BY id) AS VARCHAR)
FROM sysobjects
Select * from [dbo].[Table_5]В 1С есть специальная обработка для построения хронологических цепочек (например, что бы различать оплату и аванс относительно отгрузки), которая устанавливает на документах несовпадающее время.В 1с для решения этой проблемы :
будет ошибка уникальности.
Либо используется date (пишем '20210101'
values ('2021-01-01T00:00:00', 'test1'),
('2021-01-02T00:00:00', 'test2'),
('2021-01-03T00:00:00', 'test3'),
('2021-01-04T00:00:00', 'test4'),
('2021-01-05T00:00:00', 'test5')это не значит, что количество реально прочитанных страниц будет отличаться ровно в два раза- Согласен, если мы будем учитывать некоторые служебные указатели там будет не "Ровно в 2" но около того. +/- 10% думаю.
одна страница может хранить данные, которые при текущей выборке и не нужны совсем, но получить нужные данные нельзя, не прочитав страницу полностью.Да, кончено может, согласен, но если мы отвечаем на вопрос "Что эффективнее", для теста мы берем базу данных с одной таблицей. и последовательную запись. В этом случае у вас страницы будут содержать на 90% последовательные значения. Если мы говорим про Базу данных с 1000 таблиц и запись в них будет в разнобой, конечно на одной странице будут данные разных таблиц. Но это уже не совсем чистый эксперимент.
движок не исключает возможности хранения данных размером менее размера страницы в более чем одной странице- да, это тоже так, но не совсем понимаю, как это противоречит с условной формулой (не точной но очень близкой к правде) Количество байт / размер страницы = количество страниц.
Что эффективнее работает для выборки, вполне себе есть, измеряются они в "Duration", "Reads" и "Cpu time" , затраченных на выполнение выборки при одинаковых объёмах данных. Что меньше читает с диска и меньше тратит ресурсы процессора, считается эффективнее.
кэши и статистики и следующий запрос будет работать по-другому- это вообще из другой оперы. Для оценки эффективности можно замерять и на холодный кэш и на разогретый, и это про построение плана запросов.
сказали, что тут решается через обращение к реквизиту и никакой запрос не нужен
А есть видеокурсы, мануалы?
Выборка.Следующий() забыл ...