Здравствуйте.
Есть конфигурация УТ и два программиста, что её разрабатывают используя хранилище. У каждого программиста есть копия боевой конфы УТ, в которой они "тренируются" со своими изменениями (т.к. конфигуратор может открыть единовременно только один пользователь).
В итоге это уже три базы (боевая и две её копии), каждая размером под 100ГБ. Всего ~300ГБ. Сегодня они запросили ещё одну копию максимально сближенную по актуальности с боевой конфой УТ. Это ещё 100Гб.
Как-то настораживает.
А если у им потребуется редактировать ещё какую-нибудь другую конфу, выньте-дайте ещё 500Гб?
Или такой подход это единственный стабильный путь разработки?

2020г, серьезно, экономия на дисках для программистов? крупная компания возьмет в аренду степлер?

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

ЗЫ. Тем более 100Г - это на так много.

(0) А меня настораживает настороженность.

накой вообще в торговле тянуть 100Г информации?

(4) 100 розничных точек с миллионным оборотом каждая? )))

(0) Это не проблема. А вот когда рабочая база размером 6ТБ...

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

(0) "Как-то настораживает"
Варианты есть, конечно. Но в наше время дешевле платить за место на дисках, чем ухудшением качества/скорости процесса.

(0)Ну вы же на тестовое окружение наверняка какой-то шлак дали,то чего париться тогда

(6) А что в твоей базе 6 Тб? Сколько записей в самой большой таблице?

Т.е. других вариантов нет. EDT и GIT не решат вопрос?

(10) Данные, конечно. Сколько записей мне пофиг, пока не тормозит, а как будет тормозить - специально обученные люди этим займутся :)

(0)
1) базы крошечные и объёмы SSD/полки меньше 2 Тбайт не обсуждаются
2) базы на сиквеле сжимаются 1:3
3) в тестовых базах легко удаляются атташменты, версии объектов, ненужные для отладки в данный момент таблицы непосредственно на сиквеле
4) для отладки легко используются свёрнутые базы с набором данных за последний год

(11) ты путаешь кодирование(метаданные) и отладку (данные)

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
Т.е. других вариантов нет. EDT и GIT не решат вопрос?

(15) см. (14)

(0) Можно сжать таблицы. Раза в 4 сожмет. Для дева нормально

(15) Это про другое

EDT, GIT (и примкнувший к ним RegExp) решат вопрос, но добавят своих.

Не мешай разработчикам. Пока, по твоим словам, они всё делают правильно. Ключевым ресурсом рекомендую считать время, поэтому автоматизируй архивации, тестирования и всё, что они попросят. Это дешевле и лучше.

(0) 3 базы ) у меня 160, из них 35 больше 100 гиг, из них две больше терабайта

это только дев

либо находить место - либо как то кастрировать базу.
2 кстати совсем не тривиально.
есть еще вариант - покрытие тестами и база без данных.
но это самый сложный вариант

кстати для многотеррабайтных баз последний вариант практически единственно возможный

по базе (каждой базе) и одна вчерашняя копия - это самый минимум для разработки

(24) ОФФ: вот всегда твой ник хотелось поставить перед ником еще одного товарища с мисты))))

(23) синтетика наше всё

(15) И как ЕДТ и ГИТ решат проблему отсутствия данных? Так то пустую базу можно из CF развернуть

(15) EDT и GIT здесь непричем.
Речь про т.н. staging (или предпродакшн) - среду тестирования, максимально приближенную к боевым условиям (в идеале это должна быть полная реплика продакшна).
Просто во "взрослой" разработке он может быть один, а заливка доработок в него от всех разрабов и последующее тестирование осуществляются автоматически. Но там и команды большие (затраты на это лучше отбиваются) и инструментарий лучше и цикл разработки длиннее.
А ваши программисты просто пилят каждый в одно лицо и тестируют каждый в своем стэдже руками как могут. И это достаточно эффективно, если фичи не пересекаются, так как позволяет максимально сократить цикл разработки. И пытаться это изменить только лишь ради экономии дискового пространства - глупо.

(22) Любая "кастрация" приводит к сокрытию проблем. Если у тебя недостаточно эффективный алгоритм, то он может успешно проходить все тесты в "кастрированном" окружении, а на "боевых" объемах и взаимосвязях оказаться неработоспособным.

(29) это базы dev, а не preprod
для них полный кортеж данных нн нужен

(30) Ты точно одинэсник? Отдельный предпрод у одинэсников бывает только в полумифических компаниях, которые на пальцах одной руки пересчитать можно. 90% пилят в копиях баз, которые суть гибрид предпрода и тестовой. И не полный предпрод они только по одной причине - одинэсники не любят заморачиваться с настройкой "горячих" реплик для этих целей. Просто когда база слишком уж устаревает для тестовых целей переходят на более свежую копию.

у нас канеш не по 100гиг но баз целый зоопарк и под хранилище каждому, и тестовых несколько чисто для пользователей, не жадничайте на дисках

Сожмите базы, если места жалко: http://catalog.mista.ru/public/114634/ + http://catalog.mista.ru/public/692209/ , будет раза в три-десять меньше весить

Лучший способ разработки вдвоем - сидеть за одним компом и ловить друг друга на ошибках ;) и место экономится

(13) ну какое сжатие, базы-то средненькие.

(0) вышим кодерам совет - валить от работодателя, который более скряга чем Плюшкин!

(20) проглот!

(31) сейчас точно одинэсник
препрод готовим для каждого, поскольку mdf ERP ближе к 300 Гбайт, а баз десятки, тем более в момент подготовки релиза

Вы что несёте? Да они на операциях сжатия-разжатия потратят больше времени (читай: денег)... Если не ошибаюсь, диск в 1-2 ТБ стоит в пределах 10 тыс. руб., если они не будут тратить время на оптимизацию - то за неделю этот диск окупят.

(19) (20) (24) (28) спасибо всем за пояснение, будем пробовать :-)

(39) диск медленнее процессора, бэкап скуля со сжатием делается быстрее, чем без сжатия, например. и восстановление такого бэкапа тоже быстрее.

(39) А ты пробуй сво1 468sx заменить хотя бы на селерон дуо два...