Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, wraithik, Вы писали:

vsb>>>Здравствуйте, Буравчик, Вы писали:

vsb>>>>>Обычно добавляют булевский столбец типа актуальные данные или нет.

Б>>>>И при добавлении еще менять булевый столбец, зачем?

vsb>>>Чтобы запросы делать не через одно место.

W>>А булевский столбец мы будем триггером обновлять по все таблице... отличный вариант.

vsb>Чего? При редактировании записи проставляешь false отредактированной записи, true новой. Какой ещё триггер? Вместо одного insert получаешь insert + update. Отличий почти нет. А производительность select-ов небо и земля. Если партиционировать, то вообще разницы не будет.

Если инсерт в середину делаем? Или считаем только всегда в конец?
Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.

Здравствуйте, wraithik, Вы писали:

W>>>А булевский столбец мы будем триггером обновлять по все таблице... отличный вариант.

vsb>>Чего? При редактировании записи проставляешь false отредактированной записи, true новой. Какой ещё триггер? Вместо одного insert получаешь insert + update. Отличий почти нет. А производительность select-ов небо и земля. Если партиционировать, то вообще разницы не будет.

W>Если инсерт в середину делаем? Или считаем только всегда в конец?

Речь про историю изменений, что ещё за инсерт в середину. История всегда в конец дописывается.

W>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.

Ну любители писать логику на стороне сервера могут и хранимку написать, я предпочитаю писать код в приложении, а не в базе, но сути это не меняет. Кто-то забудет, получит по башке и вспомнит. А так и триггер можно отключить, а то чего он мешает базу портить (: А триггер, если есть желание, будет достаточно простой: в update проверяем, что ставится false на тот флажок; в insert проверяем, что ставится true, а у (n-1)-й записи проставлен false. Всё вытаскивается моментально.

Здравствуйте, vsb, Вы писали:

vsb>Речь про историю изменений, что ещё за инсерт в середину. История всегда в конец дописывается.

Да что ты... Про изменения задним числом не слышал?

W>>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.

vsb>Ну любители писать логику на стороне сервера могут и хранимку написать, я предпочитаю писать код в приложении, а не в базе, но сути это не меняет. Кто-то забудет, получит по башке и вспомнит. А так и триггер можно отключить, а то чего он мешает базу портить (: А триггер, если есть желание, будет достаточно простой: в update проверяем, что ставится false на тот флажок; в insert проверяем, что ставится true, а у (n-1)-й записи проставлен false. Всё вытаскивается моментально.

Это пофиг где ты пишешь. Должен быть атомарный вызов чего-то, что не сломает логику.
По мне так самое верное когда есть движок, который дает бизнес-объекты, и всю логику ты пишешь на них, а не лезешь каждый раз в SQL.

Здравствуйте, wraithik, Вы писали:

vsb>>Речь про историю изменений, что ещё за инсерт в середину. История всегда в конец дописывается.

W>Да что ты... Про изменения задним числом не слышал?

Про уголовную ответственность за подделку документов слышал (: Не, поменять-то можно, структура-то позволяет. Если это надо редко. Если это надо очень часто, другой вопрос, тут уже связный список надо делать.

W>>>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.

vsb>>Ну любители писать логику на стороне сервера могут и хранимку написать, я предпочитаю писать код в приложении, а не в базе, но сути это не меняет. Кто-то забудет, получит по башке и вспомнит. А так и триггер можно отключить, а то чего он мешает базу портить (: А триггер, если есть желание, будет достаточно простой: в update проверяем, что ставится false на тот флажок; в insert проверяем, что ставится true, а у (n-1)-й записи проставлен false. Всё вытаскивается моментально.

W>Это пофиг где ты пишешь. Должен быть атомарный вызов чего-то, что не сломает логику.
W>По мне так самое верное когда есть движок, который дает бизнес-объекты, и всю логику ты пишешь на них, а не лезешь каждый раз в SQL.

Ну да, это правильно. Хотя от запросов на SQL всё равно обычно никуда не уйти, но вставка/изменение лучше всего бы в одном месте, тем более, что и всякие права проверять централизованно проще и надёжней.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, wraithik, Вы писали:

vsb>>>Речь про историю изменений, что ещё за инсерт в середину. История всегда в конец дописывается.

W>>Да что ты... Про изменения задним числом не слышал?

vsb>Про уголовную ответственность за подделку документов слышал (: Не, поменять-то можно, структура-то позволяет. Если это надо редко. Если это надо очень часто, другой вопрос, тут уже связный список надо делать.

ХМ... причем тут документы и база данных. Да и от ошибок никто не застрахован. Ты живешь с воем идеальном программситком мирке. Где все по инструкции.

W>>>>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.

vsb>>>Ну любители писать логику на стороне сервера могут и хранимку написать, я предпочитаю писать код в приложении, а не в базе, но сути это не меняет. Кто-то забудет, получит по башке и вспомнит. А так и триггер можно отключить, а то чего он мешает базу портить (: А триггер, если есть желание, будет достаточно простой: в update проверяем, что ставится false на тот флажок; в insert проверяем, что ставится true, а у (n-1)-й записи проставлен false. Всё вытаскивается моментально.

W>>Это пофиг где ты пишешь. Должен быть атомарный вызов чего-то, что не сломает логику.
W>>По мне так самое верное когда есть движок, который дает бизнес-объекты, и всю логику ты пишешь на них, а не лезешь каждый раз в SQL.

vsb>Ну да, это правильно. Хотя от запросов на SQL всё равно обычно никуда не уйти, но вставка/изменение лучше всего бы в одном месте, тем более, что и всякие права проверять централизованно проще и надёжней.

Уйти. Пример 1С. Мне вообще всегда фиолетово, в какой таблице на SQL что лежит.
И пример автора я бы описал так ВЫБРАТЬ * Из РегистрСведений.КурсыВалют.СрезПоследних(&Дата).
Я прекрасно понимаю во что это транслируется на SQL, но к счастью, это делает платформа, а я занимаюсь полезной деятельностью, а не рутиной.

Здравствуйте, wraithik, Вы писали:

W>Если инсерт в середину делаем? Или считаем только всегда в конец?
W>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.
Стоит ещё задуматься о том, что будет, если вставка происходит в параллельных транзакциях.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, wraithik, Вы писали:

W>>Если инсерт в середину делаем? Или считаем только всегда в конец?
W>>Тут либо сторед-проц пишем, либо триггер делаем. Твой вариант инсерт+апдейт приведет к тому, что кто-то забудет что-то сделать.
S>Стоит ещё задуматься о том, что будет, если вставка происходит в параллельных транзакциях.

Вот теперь точно сторед-проц. Т.к. надо сперва блокировку сделать, а потом менять. Иначе будет весело, но потом, и не очень.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, Softwarer, Вы писали:

S>>К BigQuery у меня претензий нет (возможно, потому, что я с ним не работал). А вот зачем складывать данные так, чтобы для тривиального запроса требовалось завязываться узлом — вопрос, назовём так, открытый.

Б>А как удобнее было бы складывать данные?

вроде стандартное решение: две таблицы
1) основная
2) архивная
при изменении, старые значение вставляются в архив
потом, если потребуется история, можно вытянуть из архива,
в главной всегда актуальная инфа.

Здравствуйте, varenikAA, Вы писали:

AA>вроде стандартное решение: две таблицы
AA>1) основная
AA>2) архивная
AA>при изменении, старые значение вставляются в архив
AA>потом, если потребуется история, можно вытянуть из архива,
AA>в главной всегда актуальная инфа.

Имхо, ты решил проблему, которой у автора нет.
Усложнил систему без необходимости для этого.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, varenikAA, Вы писали:

AA>>вроде стандартное решение: две таблицы
AA>>1) основная
AA>>2) архивная
AA>>при изменении, старые значение вставляются в архив
AA>>потом, если потребуется история, можно вытянуть из архива,
AA>>в главной всегда актуальная инфа.

Б>Имхо, ты решил проблему, которой у автора нет.
Б>Усложнил систему без необходимости для этого.

Спросили как хранить исторические данные.
Да, конечно, проще cte написать, проще вообще одну таблицу на все приложение.
Особенно, если учесть,что исторические данные быть может нужны лишь при просмотре единственной записи.