A
Тогда вполне нормально
Спасибо большое)
Пошёл писать бд и создавать таблицы
А дальше вьюхи хранимые процедуры триггеры и т д) не сильно люблю бд в разработке 😅
Size: a a a
2020 April 13
A
Всем спокойной ночи)
SB
Проверить мой дизайн я начинающий, поэтому строго не судите
Условия:
Создаётся приложение для сбора и анализа информации с внешних датчиков. В
приложении выделены следующие сущности:
• Канал измерения – описывает канал поступления информации (датчик).
Характеризуется уникальным идентификатором, именем, типом канала.
• Измерительная сессия – один сеанс измерения. Основные характеристики: время
начала и завершения, набор задействованных каналов. Опционально может
присутствовать указание на пользователя, проводившего измерение.
• Измерение – совокупность измеренной величины, временной отметки, единиц
измерения. Измерение соотносится с измерительной сессией и каналом
измерения.
Необходимо разработать реляционное хранилище для указанных сущностей.
Вот мой дизайн
Условия:
Создаётся приложение для сбора и анализа информации с внешних датчиков. В
приложении выделены следующие сущности:
• Канал измерения – описывает канал поступления информации (датчик).
Характеризуется уникальным идентификатором, именем, типом канала.
• Измерительная сессия – один сеанс измерения. Основные характеристики: время
начала и завершения, набор задействованных каналов. Опционально может
присутствовать указание на пользователя, проводившего измерение.
• Измерение – совокупность измеренной величины, временной отметки, единиц
измерения. Измерение соотносится с измерительной сессией и каналом
измерения.
Необходимо разработать реляционное хранилище для указанных сущностей.
Вот мой дизайн
Единственное, что могу сказать, первичные ключи можно называть просто ID, а в связанной таблице внешний ключ соответственно <внешняя таблица>ID, как у вас. Но это не ошибка, так вроде все верно.
ch
Единственное, что могу сказать, первичные ключи можно называть просто ID, а в связанной таблице внешний ключ соответственно <внешняя таблица>ID, как у вас. Но это не ошибка, так вроде все верно.
Id + имя таблицы в идеале
ch
Проверить мой дизайн я начинающий, поэтому строго не судите
Условия:
Создаётся приложение для сбора и анализа информации с внешних датчиков. В
приложении выделены следующие сущности:
• Канал измерения – описывает канал поступления информации (датчик).
Характеризуется уникальным идентификатором, именем, типом канала.
• Измерительная сессия – один сеанс измерения. Основные характеристики: время
начала и завершения, набор задействованных каналов. Опционально может
присутствовать указание на пользователя, проводившего измерение.
• Измерение – совокупность измеренной величины, временной отметки, единиц
измерения. Измерение соотносится с измерительной сессией и каналом
измерения.
Необходимо разработать реляционное хранилище для указанных сущностей.
Вот мой дизайн
Условия:
Создаётся приложение для сбора и анализа информации с внешних датчиков. В
приложении выделены следующие сущности:
• Канал измерения – описывает канал поступления информации (датчик).
Характеризуется уникальным идентификатором, именем, типом канала.
• Измерительная сессия – один сеанс измерения. Основные характеристики: время
начала и завершения, набор задействованных каналов. Опционально может
присутствовать указание на пользователя, проводившего измерение.
• Измерение – совокупность измеренной величины, временной отметки, единиц
измерения. Измерение соотносится с измерительной сессией и каналом
измерения.
Необходимо разработать реляционное хранилище для указанных сущностей.
Вот мой дизайн
А обязательно ручкой на листочке?
V
Смотрю сейчас профайлером многопоточной приложение. У меня в нем генерируется огромное количество маленьких одинаковых структур. 1,5 гига за ~2 минуты работы. Если исходить из того, что все они реально нужны для работы алгоритма, можно как то это оптимизировать? Выравнивание структур, создание большого пула структур в начале работы каждого потока, а потом из этого пула дергать и т.д.? Что можно придумать чтобы не дрочить gc?
EA
Смотрю сейчас профайлером многопоточной приложение. У меня в нем генерируется огромное количество маленьких одинаковых структур. 1,5 гига за ~2 минуты работы. Если исходить из того, что все они реально нужны для работы алгоритма, можно как то это оптимизировать? Выравнивание структур, создание большого пула структур в начале работы каждого потока, а потом из этого пула дергать и т.д.? Что можно придумать чтобы не дрочить gc?
Покажи структуру, можешь поискать паттерны "Легковес" или Flyweight
V
Покажи структуру, можешь поискать паттерны "Легковес" или Flyweight
Структура типа point - упорядоченная пара интов
V
Покажи структуру, можешь поискать паттерны "Легковес" или Flyweight
Это про создание через копирование?
EA
Это про создание через копирование?
Не совсем.
Если так много структур, то они часто могут повторяться?
Если так много структур, то они часто могут повторяться?
V
Не совсем.
Если так много структур, то они часто могут повторяться?
Если так много структур, то они часто могут повторяться?
Ща, дочитаю, подумаю. Пока выглядит как то что надо, странно что сам не додумался.
Структур всего N вариантов разных, и для каждой из них я уже отдельно посчитал хэшкоды в отдельный массив, чтобы не считать каждый раз) теперь можно подумать как это обобщить
Структур всего N вариантов разных, и для каждой из них я уже отдельно посчитал хэшкоды в отдельный массив, чтобы не считать каждый раз) теперь можно подумать как это обобщить
EA
Вариант делать реестр уникальных структур, в которых нет повторений по паре, и делать ссылки на них из списка. А в списке использовать паттерны "прокси" в котором либо пользовать конкретное значение, либо идти за ним в реестр
EA
В целом ребята в чате ещё идей накидают, или мой вариант поправят
АМ
Поскольку приложение многопоточное, надо четко понимать за что отвечают эти структуры и как они связаны с работой алгоритма внутри потока. Если жёстких связей нету, то можно сделать один словарь структур на все потоки.
АМ
Словарь обеспечит быстрый доступ и отсечет повторения
SB
Смотрю сейчас профайлером многопоточной приложение. У меня в нем генерируется огромное количество маленьких одинаковых структур. 1,5 гига за ~2 минуты работы. Если исходить из того, что все они реально нужны для работы алгоритма, можно как то это оптимизировать? Выравнивание структур, создание большого пула структур в начале работы каждого потока, а потом из этого пула дергать и т.д.? Что можно придумать чтобы не дрочить gc?
А оптимизация то для чего нужна? Памяти не хватает, время работы не устраивает? Просто очень общее описание, как мне кажется. В самом по себе дрочении gc лично я не вижу ничего плохого.
Да и вообще, структуры же на стеке хранятся, какой там gc?
Да и вообще, структуры же на стеке хранятся, какой там gc?
V
Структуры все таки не на стеке. Уж у меня точно, потому что все в коллекциях разных.
Потоки создаёт parallel.for, внутри все независимо.
Не устраивает время работы, но с количеством итераций и создаваемых структур ничего не сделать, это конструктивная особенность алгоритма (если грубо, это перебор, вычислительная задача). Пытаюсь оптимизировать все остальное.
Двумерный массив заранее сгенерированных поинтов ситуацию особо не изменил, увы
Потоки создаёт parallel.for, внутри все независимо.
Не устраивает время работы, но с количеством итераций и создаваемых структур ничего не сделать, это конструктивная особенность алгоритма (если грубо, это перебор, вычислительная задача). Пытаюсь оптимизировать все остальное.
Двумерный массив заранее сгенерированных поинтов ситуацию особо не изменил, увы
V
А вот переписывание contains-ов в коллекциях на свои, чтобы избежать упаковки-распаковки, раза 1,5 ускорило
EA
Смотрю сейчас профайлером многопоточной приложение. У меня в нем генерируется огромное количество маленьких одинаковых структур. 1,5 гига за ~2 минуты работы. Если исходить из того, что все они реально нужны для работы алгоритма, можно как то это оптимизировать? Выравнивание структур, создание большого пула структур в начале работы каждого потока, а потом из этого пула дергать и т.д.? Что можно придумать чтобы не дрочить gc?
Кстати, вариант уменьшения используемой памяти это сокращение (максимальное) области видимости переменных и жизненного цикла объекта.