Здравствуйте, vdimas, Вы писали:
V>Строки в датасете — это, грубо, маппинг сущностей-строк на индексы в массивах.
Ну, я не против того, чтобы делать это для какой-то конкретной задачи. Column-based storage вполне неплохой выбор для целого ряда нагрузок; и внутри оно организуется относительно несложно.
В том смысле, что альтернатива — это иметь массив структур заранее неизвестного (порождённого в рантайме на лету) типа.
Понятно, что сделать это можно, но авторы DataTable на это не решились. Это ок.
А вот навязывать такое в качестве реализации всем остальным... Ну, так.

S>>При этом "копировать", собственно, ничего не надо. В реализации IDataRow можно делать конвертацию на лету при помощи MemoryMarshal.

V>Можно посмотреть на такую реализацию?
Имя интерфейса перепутал.
IDataRecord, а не IDataRow.
Воображаем примерно такую штуку:

public struct DataRecord: IDataRecord
{
  private Span<byte> _rawData;
  public int GetInt32(int i) => 
    GetFieldType(i) == typeof(int)
      ? MemoryMarshal.GetReference(MemoryMarshal.Cast<byte, int>(_rawData.Slice(GetFieldOffset(i)));
      : Convert.ToInt32(GetValue(i));
  }
 ...
}

V>Это всё риторическое. ))
V>Избавление от лишних копирований — неплохая награда, чтобы вот прям так категорично...
Я пока не очень представляю, в каких сценариях я бы выбрал Unsafe вместо MemoryMarshal.

V>Если берут плюсы, то выжимают эффективность, иначе бы зачем брать плюсы?
Чтобы выжимать эффективность, в основном надо думать о динамическом построении запросов. Пока в примерах идёт передача SQL Statement в виде тупо строки, про производительность можно вообще не заикаться.
Экономим микросекунды, проигрываем секунды на неудачных планах запросов.

V>Плюсы вообще редко общаются с базой напрямую, кроме как для локальных хранилищ, но там схема данных обычно тривиальнейшая.
Ну, так и есть. Вместо "напрямую" наверняка используется какая-то существующая инфраструктура типа ODBC или ADO.
V>А если общаются с сервером, то чаще на ответной стороне сервер приложений со своим кешированием, который отдаёт ответ на предопределённые запросы через предопределённые же типизированные наборы данных. И тоже задержки малость не те, к которым привыкли в дотнете.
Сервер приложений там на чём написан? На дотнете?

V>И обычно данные справочного характера кешируются на клиенте, т.е. по сети лишний раз не гоняются, что тоже резко отличается от принятого в дотнете (по крайней мере, гдя я на это внимательно смотрел).
Эта технология строго ортогональнаа применяемой платформе. Client-side join и кэширование можно строить хоть на дотнете, хоть на плюсах, хоть на жаве. Там скорее вопросы возникают к архитектуре в крупном масштабе — типа "а как мы этот кэш инвалидируем".

Здравствуйте, vdimas, Вы писали:
V>Строки в датасете — это, грубо, маппинг сущностей-строк на индексы в массивах.
Ну, я не против того, чтобы делать это для какой-то конкретной задачи. Column-based storage вполне неплохой выбор для целого ряда нагрузок; и внутри оно организуется относительно несложно.
В том смысле, что альтернатива — это иметь массив структур заранее неизвестного (порождённого в рантайме на лету) типа.
Понятно, что сделать это можно, но авторы DataTable на это не решились. Это ок.
А вот навязывать такое в качестве реализации всем остальным... Ну, так.

S>>При этом "копировать", собственно, ничего не надо. В реализации IDataRow можно делать конвертацию на лету при помощи MemoryMarshal.

V>Можно посмотреть на такую реализацию?
Имя интерфейса перепутал.
IDataRecord, а не IDataRow.
Воображаем примерно такую штуку:

public struct DataRecord: IDataRecord
{
  private Span<byte> _rawData;
  public int GetInt32(int i) => 
    GetFieldType(i) == typeof(int)
      ? MemoryMarshal.GetReference(MemoryMarshal.Cast<byte, int>(_rawData.Slice(GetFieldOffset(i)));
      : Convert.ToInt32(GetValue(i));
  
 ...
}

V>Это всё риторическое. ))
V>Избавление от лишних копирований — неплохая награда, чтобы вот прям так категорично...
Я пока не очень представляю, в каких сценариях я бы выбрал Unsafe вместо MemoryMarshal.

V>Если берут плюсы, то выжимают эффективность, иначе бы зачем брать плюсы?
Чтобы выжимать эффективность, в основном надо думать о динамическом построении запросов. Пока в примерах идёт передача SQL Statement в виде тупо строки, про производительность можно вообще не заикаться.
Экономим микросекунды, проигрываем секунды на неудачных планах запросов.

V>Плюсы вообще редко общаются с базой напрямую, кроме как для локальных хранилищ, но там схема данных обычно тривиальнейшая.
Ну, так и есть. Вместо "напрямую" наверняка используется какая-то существующая инфраструктура типа ODBC или ADO.
V>А если общаются с сервером, то чаще на ответной стороне сервер приложений со своим кешированием, который отдаёт ответ на предопределённые запросы через предопределённые же типизированные наборы данных. И тоже задержки малость не те, к которым привыкли в дотнете.
Сервер приложений там на чём написан? На дотнете?

V>И обычно данные справочного характера кешируются на клиенте, т.е. по сети лишний раз не гоняются, что тоже резко отличается от принятого в дотнете (по крайней мере, гдя я на это внимательно смотрел).
Эта технология строго ортогональнаа применяемой платформе. Client-side join и кэширование можно строить хоть на дотнете, хоть на плюсах, хоть на жаве. Там скорее вопросы возникают к архитектуре в крупном масштабе — типа "а как мы этот кэш инвалидируем".