Как минимум, потому что это разные сущности и для операций с каждой из них серверу нужно выделить какое-то количество памяти.
Подобное выделение имеет смысл, если количество операций с двумя базами одновременно не большое.
Вообще, в корпоративных базах данных несколько сотен (а то и тысяч) таблиц это нормальное явление.
Если нужно увеличить производительность, то для этого есть другие способы:
1. стандартные: индексация таблиц, дефрагментация индексов, обновление статистики.
2.если не хватает стандартных способов: отделение физического расположения журнального файла от файла базы данных, перемещение наиболее часто используемых таблиц в отдельную storage group и помещение этой группы на более быстрые диски (SSD).
На самом деле, выделение таблиц в отдельную базу данных вам вряд ли даст вообще какое-то ощутимое изменение в быстродействии сервера БД. Поскольку накладные расходы на работу с двумя базами, конечно больше, но не настолько критично, чтоб это сказывалось на производительности.
Да, иногда для разблокировки занятого неизвестно чем файла нужно и ОСь перезагружать, но это редко.
Многие IDE позволяют удалять файлы прямо из собственного интерфейса, в других можно удалить файл из проекта не удаляя его из файловой системы, а потом руками удалить файл из ФС.
Если ваша ИДЕ не умеет ни того ни другого, то не нужный файл после закрытия его в ИДЕ и удаления из проекта можно перенести в другой каталог и потом, когда сама ИДЕ будет закрыта, удалить файл. Так же можно поставить скрипт в шедулер или в автозагрузку, удаляющий все файлы из заданного каталога, тогда после переноса можно не заботится об удалении файла - сам со временем удалится.
Кстати, чем-то подобным страдает Adobe Reader - пока не закроешь сам ридер нельзя удалить ранее открытый и закрытый файл.
Так же можно вычислять размер достаточного буфера, вызвав sprintf с первым параметром NULL, тогда она не будет никаких действий производить, но вернет вычисленный размер буфера. Потом выделяете этот объем памяти и заполняете его как обычно.
Но в целом, проще так как показал Mercury13
Согласен, поле состояния лишнее - сортируйте вывод по дате от больших к меньшим и берите первую запись - это будет актуальный пост, все остальные - история изменений.
Abdula Magomedov: В этом случае описанный вами 1 вариант вполне подходит. Дополнительно нужно предусмотреть проверки для случаев, которые вы сами и описываете. Этого не избежать, если выдвигаются подобные требования.
А в варианте с "виртуальными контейнерами" я вообще не понял о чем речь. Слово "виртуальный" когда дело доходит до конкретики вносит какую-то неопределенность :)
Mohn: Это обычное поведение Windows, никакими настройками это не лечится. Поэтому ищите другой выход. Обычный подход, как и предложил atmid , копировать с последующим удалением.
Добавлю от себя: внутри сети ходите по локальным адресам, из вне - по внешним. Это нормально. Так же как иметь разные DNS сервера для локальной сети и для внешней.
Rsa97: Сори, что-то с утра померещилось, что вы автор вопроса :-)
На сколько я знаю нет никакой автоматической точности. По умолчанию установлена точность 6 знаков после запятой, и пока вы в ручную не зададите другое значение, будет 6 знаков - автоматикой тут и не пахнет.
Учтите, что Excel в режиме общего доступа ведет себя очень плохо - таблицы пухнут как на дрожжах, время от времени таблицы рушатся без возможности восстановления. Я бы не советовал влазить в это. Общий доступ в екселе - это как костыль какой-то - больше геморрою, чем толку.
sbh: Самый правильный - portdowngrade. Да, зависимости придется то же руками разруливать, но это лучше, чем потеря данных.
Кстати, обычно порты для зависимостей требуют версию не ниже какой-то, поэтому может и не придется бороться с ними, т.к. у вас они будут выше.
Другой вариант - собрать нужную версию порта руками, но, имхо, это коряво. Потом все обновления так же придется делать руками.
sbh: По снапшотам: если диск 1, то снапшоты на уровне гипервизора, действительно приводят к потере новых данных. Но в случае использования ZFS вам никто не мешает для /var/mail например выделить отдельный раздел, для /etc - свой раздел, для /usr - свой раздел. Делайте снапшоты на уровне ZFS в /etc и /usr и данные останутся целы, т.к. они будут в /var. Или если не заморачиваться с ZFS, то для /var отдельный диск в гипервизоре.
Т.е. эти вещи надо продумывать когда вы только ставите систему. Это, кстати, касается не только фряхи.
Да - в двух версиях.
Да - можно, по умолчанию, на сколько я знаю, в VC именно динамическая библиотека используется. Выбор динамики и статики - с помощью опций компилятора или настройками проекта (что в итоге все равно дает те же опции компилятора).
Если вас интересует конкретно версия 120, то это зависит от версии VC (в разных версиях VC используются разные версии стандартной библиотеки).
Ну тут то же есть решения - раз вы имеете возможность исправлять сервер, то видимо и клиента то же можете поправить - введите в протокол обмена команду клиенту принудительно разорвать соединение и подключиться за ново. А дальше по схеме nginx.
Подобное выделение имеет смысл, если количество операций с двумя базами одновременно не большое.
Вообще, в корпоративных базах данных несколько сотен (а то и тысяч) таблиц это нормальное явление.
Если нужно увеличить производительность, то для этого есть другие способы:
1. стандартные: индексация таблиц, дефрагментация индексов, обновление статистики.
2.если не хватает стандартных способов: отделение физического расположения журнального файла от файла базы данных, перемещение наиболее часто используемых таблиц в отдельную storage group и помещение этой группы на более быстрые диски (SSD).
На самом деле, выделение таблиц в отдельную базу данных вам вряд ли даст вообще какое-то ощутимое изменение в быстродействии сервера БД. Поскольку накладные расходы на работу с двумя базами, конечно больше, но не настолько критично, чтоб это сказывалось на производительности.