Жизнь без СОЕДИНЕНИЙ … понимание и общие методы

Используя Interop Вы получаете диапазон ячеек и звоните .Merge() метод на том диапазоне.

eWSheet.Range[eWSheet.Cells[1, 1], eWSheet.Cells[4, 1]].Merge();
59
задан Community 23 May 2017 в 12:02
поделиться

7 ответов

На мой взгляд, реляционная база данных является универсальной инструмент для хеджирования ваших ставок. Современные компьютеры достаточно быстры, а СУБД достаточно хорошо оптимизированы, чтобы вы могли вырасти до вполне приличных размеров на одном устройстве. Выбирая РСУБД, вы предоставляете себе очень гибкий доступ к своим данным и возможность иметь мощные ограничения корректности, которые значительно упрощают кодирование данных. Однако СУБД не будет представлять собой хорошую оптимизацию для какой-либо конкретной проблемы, она просто дает вам гибкость, позволяющую легко изменять проблемы.

Если вы начнете быстро расти и поймете, что вам придется масштабироваться за пределы размера одной Сервер БД, вам внезапно предстоит сделать гораздо более сложный выбор. Вам нужно будет начать выявлять узкие места и устранять их. РСУБД превратится в один неприятный клубок взаимозависимости, который вам придется развязать. Чем больше взаимосвязаны ваши данные, тем больше работы вам придется выполнять, но, возможно, вам не придется полностью распутывать все это. Если вы много читаете, возможно, вы сможете обойтись простой репликацией. Если вы насыщаете свой рынок и его рост стабилизируется, возможно, вам удастся частично денормализовать и разделить на фиксированное количество серверов БД. Может быть, у вас просто есть несколько проблемных таблиц, которые можно переместить в более масштабируемое хранилище данных. Возможно, ваш профиль использования очень удобен для кеширования, и вы можете просто перенести нагрузку на гигантский кластер memcached.

Могут использоваться масштабируемые хранилища значений ключей, такие как BigTable, когда ничего из вышеперечисленного не работает, и у вас так много данных единственный тип, который даже после денормализации одной таблицы слишком много для одного сервера. На этом этапе вам нужно иметь возможность произвольно разбивать его и при этом иметь чистый API для доступа к нему. Естественно, когда данные распределены по такому количеству машин, вы можете ' У меня есть алгоритмы, требующие, чтобы эти машины много общались друг с другом, что потребовалось бы для многих стандартных реляционных алгоритмов. Как вы предполагаете, эти алгоритмы распределенных запросов потенциально могут потребовать большей общей вычислительной мощности, чем эквивалентное соединение JOIN в правильно проиндексированной реляционной базе данных, но поскольку они распараллелены, производительность в реальном времени на несколько порядков выше, чем могла бы сделать любая отдельная машина (при условии, что машина, которая могла бы хранить весь индекс, даже существует.)

Теперь, когда вы можете масштабировать массив данных по горизонтали (просто подключив больше серверов), сложная часть масштабируемости сделана. Что ж, я не должен говорить готово , потому что текущие операции и разработка в этом масштабе намного сложнее, чем односерверное приложение, но суть в том, что серверы приложений обычно легко масштабируются с помощью архитектуры без совместного использования, если они могут своевременно получать необходимые данные.

Чтобы ответить на ваш вопрос о том, как часто используемые ORM справляются с невозможностью использовать JOIN. , краткий ответ - они не . ORM расшифровывается как Object Relational Mapping, и большая часть работы ORM просто переводит мощную реляционную парадигму логики предикатов в простые объектно-ориентированные структуры данных. Большая часть того, что они вам дают, просто невозможно получить из хранилища "ключ-значение". На практике вам, вероятно, понадобится создать и поддерживать свой собственный уровень доступа к данным, который соответствует вашим конкретным потребностям. потому что профили данных в этих масштабах будут сильно отличаться, и я считаю, что существует слишком много компромиссов для того, чтобы инструмент общего назначения появился и стал доминирующим в сравнении с РСУБД. Короче говоря, вам всегда придется проделывать больше работы в этом масштабе.

Тем не менее, определенно будет интересно посмотреть, какие реляционные или другие агрегированные функциональные возможности могут быть построены на основе примитивов хранилища значений ключей. У меня действительно недостаточно опыта, чтобы прокомментировать это конкретно, но в корпоративных вычислениях есть много знаний об этом, уходящих много лет назад (например, Oracle), много неиспользованных теоретических знаний в академических кругах, много практических знаний в Google, Amazon, Facebook и др., Но знания, которые просочились в более широкое сообщество разработчиков, все еще довольно ограничены.

Однако теперь, когда множество приложений перемещается в Интернет, и все больше и больше населения мира подключено к сети, неизбежно все больше и больше приложений придется масштабировать, и передовые методы начнут выкристаллизовываться. Пробел в знаниях будет сокращен с обеих сторон облачными сервисами, такими как AppEngine и EC2, а также базами данных с открытым исходным кодом, такими как Cassandra. В некотором смысле это идет рука об руку с параллельными и асинхронными вычислениями, которые также находятся в зачаточном состоянии. Определенно захватывающее время для программиста.

а также базы данных с открытым исходным кодом, такие как Cassandra. В некотором смысле это идет рука об руку с параллельными и асинхронными вычислениями, которые также находятся в зачаточном состоянии. Определенно захватывающее время для программиста.

а также базы данных с открытым исходным кодом, такие как Cassandra. В некотором смысле это идет рука об руку с параллельными и асинхронными вычислениями, которые также находятся в зачаточном состоянии. Определенно захватывающее время для программиста.

35
ответ дан 24 November 2019 в 18:30
поделиться

Вы исходите из ошибочного предположения.

Хранилище данных не нормализует данные так же, как приложение транзакций. Соединений не "много". Их относительно немного.

В частности, вторые и третьи нарушения Нормальной формы не являются «проблемой», поскольку хранилища данных редко обновляются. И когда они обновляются, это обычно всего лишь изменение флага состояния, чтобы сделать строки измерения «текущими» и «не текущими».

Поскольку вам не нужно беспокоиться об обновлениях, вы не раскладываете вещи вниз до уровня 2NF, где обновление не может привести к аномальным отношениям. Отсутствие обновлений означает отсутствие аномалий; и без разложений и без стыков. Вы можете предварительно объединить все.

Как правило, данные DW разбиваются по схеме звезды. Это поможет вам разложить данные на числовые таблицы «фактов», которые содержат меры - числа с единицами измерения - и ссылки внешнего ключа на измерение.

Измерение (или «бизнес-объект») лучше всего рассматривать как вещь из реального мира с атрибутами. Часто сюда входят такие вещи, как география, время, продукт, покупатель и т. Д. Эти вещи часто имеют сложную иерархию. Иерархии обычно произвольные, определяются различными потребностями в бизнес-отчетности и не моделируются как отдельные таблицы, а просто столбцы в измерении, используемом для агрегирования.


Чтобы ответить на некоторые из ваших вопросов.

«это объединение должно быть выполнено. со стороны приложений ". Вид. Перед загрузкой данные «объединяются». Данные измерения часто являются объединением соответствующих исходных данных об этом измерении. Это' s соединяется и загружается как относительно плоская конструкция.

Не обновляется. Вместо обновлений вставляются дополнительные исторические записи.

«Но разве это не начинает дорожать?». Вид. Загрузка данных требует некоторой осторожности. Однако объединений отчетности и анализа не так много. Данные предварительно объединяются.

Вопросы ORM в значительной степени спорны, поскольку данные предварительно объединены. Ваша ORM сопоставляется с фактом или измерением в зависимости от ситуации. За исключением особых случаев, размеры, как правило, небольшие и полностью умещаются в памяти. Исключение составляют случаи, когда вы работаете в сфере финансов (банковское дело или страхование) или коммунальных предприятий и имеете огромные базы данных клиентов. Эти параметры клиента редко умещаются в памяти.

добавляются дополнительные исторические записи.

«Но разве это не начинает дорожать?». Вид. Загрузка данных требует некоторой осторожности. Однако объединений отчетности и анализа не так много. Данные предварительно объединяются.

Проблемы ORM в значительной степени спорны, поскольку данные предварительно объединены. Ваша ORM соотносится с фактом или измерением в зависимости от ситуации. За исключением особых случаев, размеры, как правило, небольшие и полностью умещаются в памяти. Исключение составляют случаи, когда вы работаете в сфере финансов (банковское дело или страхование) или коммунальных предприятий и имеете огромные базы данных клиентов. Эти параметры клиента редко умещаются в памяти.

добавляются дополнительные исторические записи.

«Но разве это не начинает дорожать?». Вид. Загрузка данных требует некоторой осторожности. Однако объединений отчетности и анализа не так много. Данные предварительно объединяются.

Проблемы ORM в значительной степени спорны, поскольку данные предварительно объединены. Ваша ORM соотносится с фактом или измерением в зависимости от ситуации. За исключением особых случаев, размеры, как правило, небольшие и полностью умещаются в памяти. Исключение составляют случаи, когда вы занимаетесь финансами (банковское дело или страхование) или коммунальными предприятиями и имеете огромные клиентские базы данных. Эти параметры клиента редко умещаются в памяти.

Вопросы ORM в значительной степени спорные, поскольку данные предварительно объединены. Ваша ORM сопоставляется с фактом или измерением в зависимости от ситуации. За исключением особых случаев, размеры, как правило, небольшие и полностью умещаются в памяти. Исключение составляют случаи, когда вы занимаетесь финансами (банковское дело или страхование) или коммунальными предприятиями и имеете огромные клиентские базы данных. Эти параметры клиента редко умещаются в памяти.

Вопросы ORM в значительной степени спорны, поскольку данные предварительно объединены. Ваша ORM соотносится с фактом или измерением в зависимости от ситуации. За исключением особых случаев, размеры, как правило, небольшие и полностью умещаются в памяти. Исключение составляют случаи, когда вы занимаетесь финансами (банковское дело или страхование) или коммунальными предприятиями и имеете огромные клиентские базы данных. Эти параметры клиента редко умещаются в памяти.

21
ответ дан 24 November 2019 в 18:30
поделиться

Он сериализует файл DBMDL. Это занимает довольно много времени в зависимости от размера / сложности вашего проекта. У одного из них, например, 150 МБ, и на выполнение всех «операций» уходит почти 20 минут.

И вы можете контролировать это только до определенной степени. После этого вы просто выполняете запрос SQL и ждете.

Реляционная модель, созданная для упрощения жизни разработчика, а не для достижения суперскорости всегда и несмотря ни на что.

Это аналогично сборке по сравнению с языками более высокого уровня, реляционная модель является языком более высокого уровня.

Вы можете прочитать статью в моем блоге

, в которой я пытаюсь объяснить различия между несколькими широко используемыми моделями баз данных.

14
ответ дан 24 November 2019 в 18:30
поделиться

Когда вы денормализуете данные таким образом, вы делаете это, чтобы избежать затрат на объединение разрозненных элементов; вы соглашаетесь с тем, что некоторые данные могут дублироваться и что определенные способы их объединения могут быть трудными для повышения производительности при использовании простых запросов.

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

В идеале вы можете сделать один запрос для любого набора данных, который вам нужен. На практике вам не нужно использовать более двух или трех запросов для любого аспекта вашего приложения, и любое соединение на уровне приложения будет скорее тривиальным извлечением материала из отдельных наборов результатов для вставки в представление.

Такие вещи действительно нужны только для действительно массивных наборов данных, и здесь есть все виды компромиссов. Приведу только один пример: BigTable не может выполнять агрегированные запросы, такие как подсчет. Его можно использовать, чтобы получить примерно точную цифру - в том смысле, что если у вас есть, скажем, 12 149 173 записей, из которых 23 721 были добавлены за последний час, на самом деле не имеет значения, что лучшее, что вы можете узнать, это то, что у вас есть «около 12 100 000 записей». Если ваше приложение зависит от знания точной цифры в любой момент времени, то вам не следует использовать для этого BigTable, это общее отношение.

на самом деле не имеет значения, если лучшее, что вы можете узнать, это то, что у вас «около 12 100 000 записей». Если ваше приложение зависит от знания точной цифры в любой момент времени, то вам не следует использовать для этого BigTable, это общее отношение.

на самом деле не имеет значения, если лучшее, что вы можете узнать, это то, что у вас «около 12 100 000 записей». Если ваше приложение зависит от знания точной цифры в любой момент времени, то вам не следует использовать для этого BigTable, это общее отношение.

4
ответ дан 24 November 2019 в 18:30
поделиться

Я думаю, что в таких ситуациях вы будете в значительной степени сами по себе, и вам придется все катить самостоятельно. Я там не был, но рассматривал это для некоторых наших проектов. Вы можете стать довольно большими с реляционными базами данных (как демонстрирует SO), так что пока я буду продолжать наслаждаться совершенством отношений.

0
ответ дан 24 November 2019 в 18:30
поделиться

Как правило, хранилище данных построено на использовании объединений и данных, разделенных на измерения и таблицы фактов (с так называемыми "звездообразными схемами" "и т. д.)

Соединения часто предварительно вычисляются и сохраняются в виде ненормализованных таблиц.

Мне не известны какие-либо инструменты ORM, которые работают с системами баз данных, которые не допускают объединения, поскольку они обычно не используются рассматриваются как традиционные реляционные базы данных.

0
ответ дан 24 November 2019 в 18:30
поделиться

В таких приложениях, как facebook, очень мало изменений данных, большую часть времени пользователи публикуют новые элементы. Так что тот факт, что несколько записей требуют обновления при изменении элемента, представляет меньшую проблему.

Это позволяет данным не изменяться. нормализованы, не затрагивая общие проблемы с обновлениями.

Приложения, такие как Amazon, могут позволить себе загружать все данные для одного пользователя в ОЗУ (в конце концов, насколько велика корзина для покупок?), затем обновлять данные в ОЗУ и записывать их как единый элемент данных .

Еще раз устраняя необходимость иметь большая часть данных нормализована.

Вы торгуете масштабированием ради простоты разработки приложений, поэтому, если вам не нужно масштабировать до больших высот, вы можете сохранить легкость разработки приложений, которую обеспечивает РСУБД.

3
ответ дан 24 November 2019 в 18:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: