База в форме SQL, если она будет очень сильно расти в размерах(справочник будет увеличиваться). страшно ли это или нет?

О, найн !

сморя с какой стороны посмотреть, но в принцыпе (1)...

Для производительности и всего прочего

"сильно расти" - это в тысячах сколько ?

Страшна - падает с большим грохотом...
Маленькая - падает тихо....

Сильно это каждый день около ста записей в справочник

(6) Дай задачу посмотреть - откуда такое кол-во новых записей ?

Приходуют бланки билетов и раздают их кассирам, они потом отчитыватся, такой-то билет на такую-то сумму, от такого-то поставщика. Я как думаю сделать на забалансовом счете считать их, но получается что каждый билет будет представлять запись в справочнике. Может как по другому подскажет кто.

(0) Это не страшно, если справочник будет невидимым для пользователя.
Если же это номенклатура, то надо придумать что-то еще. А какая задача?
Если что-то связанное с оперативным учетом, то безусловно надо делать на регистрах.

(8) Билет - это типичный документ.

(10+) Документ "Билеты за день" - аналог банковской выписки.

А поподробнее можно про билет-документ, чего-то не догоняю

(11) Не совсем так. В "Торговле и Складе" есть кассовые чеки. Они в конце смены сворачиваются в один большой документ.

(12) Билеты пронумерованы, имеют ли дату? Что вообще за билеты?
Это полигон что ли, талоны на въезд?

Кстати у меня только бухгалтерия, так-что надо выкручиваться.

билеты пронумерованы, а надо чтоб учет велся именно каждого билета по номерам.

(15) Я так понимаю, что кассир принимает театральные билеты на реализацию что ли?
Что у вас там в реальности то?

Ну типа того

Шутники? 100 записей в день много???

Ну я так понимаю, что напрашивается документ
"Выдача билетов кассиру"
и документ
"Отчет кассира"

Смотреть, а сколько же еще билетов должен кассир, надо либо на регистре, либо на заб. счете (но тогда надо заводить действительно справочник, но невидимый для юзера).

А ничего что справочник будет расти со страшной силою?

(21) Регистр тоже растет со временем. В принципе, если посмотреть на структуру базы, тот же самый DBF/таблица SQL.

Для экономии на росте индексов можно сделать длину полея Код или Наименование=0.

Можно чистить древние билеты документом наподобие ЗакрытиеМесяца.

Но как-то неохота справочник заводить, как вообще учитывают бланки строгой отчетности.

Вообще то билеты - это бланки строгой отчетности...
И есть правила работы с ними...

Можно и без справочника сделать, но некоторые отчеты молотить будут долго.... Хотя при 100 билетах в день чего заморачиваться...

У нас в бухии справочник уже под 20000 с начала года... Движений - до горы...

И какие правила работы с бланками строгой отчетности. и как обойтись без справочника?

Наверное, действительно, просто обработкой, которая собирает остатки билетов в следующий документ...

Совсем в тему. Как учесть приплод крупного рогатого скота, произошедший арендованном вагоне с причинением ущерба последнему (в виде непредусмотренных загрязнений)?

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

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

(28) по крайней мере, 10-20гиг не есть предел. С 100 записями (и с 1000 тоже) тебе оочень долго расти до такого объема.

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

Как раз в данный момент занимаюсь подобным. В спр-ке 400 000 записей.
документами не советую - будет медленнее. Выход:
2 справочник с аналогичной структурой, периодическая обрезка рабочего с сбросом записей во 2-й. На форме кнопка "Посмотреть старые".

Мож я кому-то я испорчу настроение, но...
Если базу 1с 7.7 из SQL потребуется выгрузить в файл, то при огромном объеме базы (когда размер zip-файла с выгрузкой превысит 2 Гб) выгрузка загнется.
Это ограничение zip-библиотеки, встроенной в движок 1с 7.7.
Но чтоб такую базу наколбасить - надо постараться.

Я наверно всех задолбал, а что если сделать до черта проводок не сильно объем будет расти, и чем ето черевато?

справочник номенклатуры - бланки билетов, подчиненный справочник - билетыВрозницу ...расходуем номенклатуру, в документах о реализации - элементы подчиненного справочника ...на такого типа конфу пялюсь третью неделю)
...в случае чего ,чтоб база громко не падала) я б разнес ее на 2 или более файловые группы, разнести  на разные рэйды или винты ,скажем, быстрорастущие справочники- на отдельный винт, регистры на другой, если с количеством RAID-ов напряг, то по крайней мере оперативней можно будет делать бэкап-восстановление файлов базы.

нормальных идей не наблюдается....

У меня в аптеке каждый провизор выбивает в среднем 100-150 чеков в день. На каждый чек формируется отдельный документ (в среднем 3-5 строк). Никаких сверток. Больше 3 лет работают. Никаких "замедлений" при вводе текущей информации не видно. Отчеты за продолжительные периоды в принципе не делаются. Анализ движений регистров по этим чекам выполняется тоже довольно быстро (в том числе за продолжительные периоды). Машина, на которой это работает - Р100.

Можно было бы не создавать море элементов справочника, а завести один элемент, а номера учитывать ка субконто по забалансовому счету.
Субконто1: Бланк [Справочник]
Субконто2: Номер [Строка или Число в зависимости от типа номера]
А приходовать билеты в кассу одной строкой с номера по номер, а в модуле проведения автоматически размножать.

http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=2544

Совершенно согласен с Xelon, не нужно в справочнике билеты создавать постоянно новую запись, а нужен подчиненный справочник. Эта идея напоминает, например, когда необходимо учитывать котрагентов в разрезе оплат по счетам. Не создается же для этой цели в справочнике новый контрагент!  И вообще любые бланки строгой отчетности учитываются в количественном и суммовом выражении. Никогда не видел, чтобы кто-то в 1С учитывал их еще и по номерам!