От Новичка: Табличный документ или справочник ?

@BVladimir2 · Регистрация: 26.02.2013

Author24 — интернет-сервис помощи студентам

Дано: Некая таблица в которой примерно 500 тыс. ячеек со значениями.

Вопрос: Распихать все данные по справочникам и работать с ними или разместить все в одном табличном документе и забирать данные прямо из него ? Что в 1С быстрее работать будет ?

Спасибо.

@duk337 · 22.03.2013, 08:50

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

@BVladimir2 · 22.03.2013, 11:13 **[ТС]**

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

И вот хочу понять, что будет быстрее в 1С работать, если я все данные из таблицы перенесу в справочники и буду из них данные выбирать или же если работать с табличным документом в 1С ? В нем же можно находить нужные ячейки и т.п. ?

@duk337 · 22.03.2013, 11:18

Ещё раз медленно:
ч т о н а д о р а з м е с т и т ь в 1 С? Не с точки зрения ячеек ёкселя, а с точки зрения данных 1с

@BVladimir2 · 22.03.2013, 11:35 **[ТС]**

примерно 20 000 строк с текстовыми наименованиями и примерно 20 столбцов с цифрами. т.е. к каждой текст.строке идет по 20 чисел с разным кол-вом знаков после запятой. Нужно забирать эти цифры, манипулировать с ними и возвращать обратно иногда. Отбор, соответственно, необходимо производить по текстовым наименованиям строк.
Вроде все сказал. Это как бы очень большая смета где много статей и по каждой статье много цифр...

@duk337 · 22.03.2013, 12:03

Сообщение от BVladimir2

Вроде все сказал.

Увы, ничего... Вы в какие реквизиты будете качать смету? В какую конфигурацию, хотя бы. Если самописка - то ведь с данными надо как-то работать, а не только закачивать...

Добавлено через 10 минут
Справка:
Смета - это головоломная иерархия, прежде всего (сборники, разделы, параграфы, пункты и т.д.).
Есть иерархия справочника, что, собственно и позволяет обходиться одним объектом. НО! Работа со сметой имеет массу особенностей, которые заставляют держать иерархические группы в отдельных справочниках. В этом случае используется регистр сведений, в котором набор измерений включает все группы иерархии.
Совет:
Озаботьтесь не скоростью, а алгоритмом.

@BVladimir2 · 22.03.2013, 15:42 **[ТС]**

Мне видится, как минимум, два варианта в моем, сравнительно, простом случае:

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

2.Все данные в одном большом табличном документе и в нем ищутся строки с нужными объектами и статьями затрат, а из столбцов берутся цифры.

Вопрос, собственно, какой из вариантов будет работать у пользователя быстрее ?

@Xomych · 22.03.2013, 15:49

А как в эту таблицу данные попадают?

@Dethmontt · 22.03.2013, 16:22

первый вариант

Сообщение от BVladimir2

1.В одном справочнике наименования объектов, в другом наименования статей затрат, ~~в третьем цифры~~, т.е. значения статей затрат. Чтобы что-то делать мне нужно будет создавать виртуальтную таблицу и с помощью языка запросов получать выборки и уже с ними работать.

Кроме этого:

Сообщение от BVladimir2

в третьем цифры,

Цифры в регистре

@duk337 · 23.03.2013, 12:22

Сообщение от BVladimir2

2.Все данные в одном большом табличном документе и в нем ищутся строки с нужными объектами и статьями затрат, а из столбцов берутся цифры.

это Вы просто так по клавишам стучали. Конфигурация - это модель реальности. Естественно, объекты строительства и статьи затрат в одной куче лежать не могут. Я ещё раз хочу дать совет: продумайте алгоритм прежде чем сформируете структуру. Нарисуйте на бумажке, если в голове не помещается.

@BVladimir2 · 26.03.2013, 13:28 **[ТС]**

Сообщение от duk337

это Вы просто так по клавишам стучали. Конфигурация - это модель реальности. Естественно, объекты строительства и статьи затрат в одной куче лежать не могут. Я ещё раз хочу дать совет: продумайте алгоритм прежде чем сформируете структуру. Нарисуйте на бумажке, если в голове не помещается.

Да как раз-то с алгоритмом все более ли менее ясно - простой он сравнительно. Мне не нужно писать большую конфигурацию - речь об отдельной задаче, т.е., по сути, замене Эксэла.

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

@delphi_Int · 26.03.2013, 20:30

По ограничениям 1С Вы не можете иметь более 10 000 строк в Таб. Части Документа ! Но даже если у Вас их будет 9 990, Вы хоть представляете сколько по времени он будет Открываться/Записываться (что ещё дольше). Даже если все будет на оптимуме, это будет Самый Самый Самый СамыйСамый СамыйСамый СамыйСамый СамыйСамый СамыйСамый тугой Документ в1С

@Xomych · 27.03.2013, 10:10

Сообщение от delphi_Int

По ограничениям 1С Вы не можете иметь более 10 000 строк в Таб. Части Документа ! Но даже если у Вас их будет 9 990, Вы хоть представляете сколько по времени он будет Открываться/Записываться (что ещё дольше). Даже если все будет на оптимуме, это будет Самый Самый Самый СамыйСамый СамыйСамый СамыйСамый СамыйСамый СамыйСамый тугой Документ в1С

На самом деле это не так

У меня есть документы >10тыщ строк и они работают и нормально открываются и проводятся

@duk337 · 27.03.2013, 10:13

Не по теме:

"ах, это, братцы, не о том...":no:

@Xomych · 27.03.2013, 10:16

Сообщение от BVladimir2

Да как раз-то с алгоритмом все более ли менее ясно - простой он сравнительно. Мне не нужно писать большую конфигурацию - речь об отдельной задаче, т.е., по сути, замене Эксэла.

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

А почему бы не использовать SQL таблицу? Быстро, надежно, большие объемы данных можно хранить.

@duk337 · 27.03.2013, 10:20

Вы о чём, ребята? Прежде всего - какие функции должна выполнять эта "таблица", как актуализируется, что там хранится, что вычисляется, как её показывать оптимальнее... Это первое, что в голову приходит, а на самом деле там воз алгоритмических граблей.
Кто мешает попробовать десяток вариантов? Дело-то минутное

@BVladimir2 · 27.03.2013, 10:40 **[ТС]**

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

А кстати, не по теме, "из SQL" данные в 1С можно передавать через ODBC, как я понимаю. Но вопрос в том, сильно ли будет тормозить 1С если данные будут обновлятся несколько раз в секунду (например, бирж.котировки) ? Вообще реально ли использовать платформу 1С для получения данных с биржи, скажем через Quik, и последующую их регистрацию в базе данных ?

@Xomych · 27.03.2013, 10:51

Сообщение от BVladimir2

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

А кстати, не по теме, "из SQL" данные в 1С можно передавать через ODBC, как я понимаю. Но вопрос в том, сильно ли будет тормозить 1С если данные будут обновлятся несколько раз в секунду (например, бирж.котировки) ? Вообще реально ли использовать платформу 1С для получения данных с биржи, скажем через Quik, и последующую их регистрацию в базе данных ?

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

@duk337 · 27.03.2013, 11:43

Сообщение от BVladimir2

мне нужна скорее альтернатива Эксэлу

это ничего не сказать, в ёкселе можно рссчитывать всё - и нельзя ничего. Любая конфигурация 1с - это "альтернатива Эксэлу". Создайте комфортную среду для функционирования модели, используя справочники, регистры, документы - там, где это оптимально. Вам кажется, что форма хранения исходной инфы - это и интерфейс для работы. ЗАБЛУЖДЕНИЕ. Даже хранить её надо так, чтобы не было мучительно больно при рассчетах.

@Dethmontt · 27.03.2013, 17:57

предлагаю переходить на MS ACCESS
Книга учета доходов и расходов предпринимателя
Разграничение прав доступа пользователя по организации

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	27.03.2013, 11:43	19
	Сообщение от BVladimir2 мне нужна скорее альтернатива Эксэлу это ничего не сказать, в ёкселе можно рссчитывать всё - и нельзя ничего. Любая конфигурация 1с - это "альтернатива Эксэлу". Создайте комфортную среду для функционирования модели, используя справочники, регистры, документы - там, где это оптимально. Вам кажется, что форма хранения исходной инфы - это и интерфейс для работы. ЗАБЛУЖДЕНИЕ. Даже хранить её надо так, чтобы не было мучительно больно при рассчетах. 0

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
		1
	От Новичка: Табличный документ или справочник ? 21.03.2013, 23:58. Показов 2719. Ответов 19 Метки нет (Все метки) Дано: Некая таблица в которой примерно 500 тыс. ячеек со значениями. Вопрос: Распихать все данные по справочникам и работать с ними или разместить все в одном табличном документе и забирать данные прямо из него ? Что в 1С быстрее работать будет ? Спасибо. 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	22.03.2013, 08:50	2
	регистр сведений - наиболее подходящий вариант, поскольку он универсален, а понять, что Вам надо разместить, невозможно. 0

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
	22.03.2013, 11:13 [ТС]	3
	Просто таблица в Экселе которую надо периодически обновлять и забирать из нее данные, типа суммы по строкам или столбцам, выборки разные и т.п. И вот хочу понять, что будет быстрее в 1С работать, если я все данные из таблицы перенесу в справочники и буду из них данные выбирать или же если работать с табличным документом в 1С ? В нем же можно находить нужные ячейки и т.п. ? 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	22.03.2013, 11:18	4
	Ещё раз медленно: ч т о н а д о р а з м е с т и т ь в 1 С? Не с точки зрения ячеек ёкселя, а с точки зрения данных 1с 0

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
	22.03.2013, 11:35 [ТС]	5
	примерно 20 000 строк с текстовыми наименованиями и примерно 20 столбцов с цифрами. т.е. к каждой текст.строке идет по 20 чисел с разным кол-вом знаков после запятой. Нужно забирать эти цифры, манипулировать с ними и возвращать обратно иногда. Отбор, соответственно, необходимо производить по текстовым наименованиям строк. Вроде все сказал. Это как бы очень большая смета где много статей и по каждой статье много цифр... 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	22.03.2013, 12:03	6
	Сообщение от BVladimir2 Вроде все сказал. Увы, ничего... Вы в какие реквизиты будете качать смету? В какую конфигурацию, хотя бы. Если самописка - то ведь с данными надо как-то работать, а не только закачивать... Добавлено через 10 минут Справка: Смета - это головоломная иерархия, прежде всего (сборники, разделы, параграфы, пункты и т.д.). Есть иерархия справочника, что, собственно и позволяет обходиться одним объектом. НО! Работа со сметой имеет массу особенностей, которые заставляют держать иерархические группы в отдельных справочниках. В этом случае используется регистр сведений, в котором набор измерений включает все группы иерархии. Совет: Озаботьтесь не скоростью, а алгоритмом. 0

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
	22.03.2013, 15:42 [ТС]	7
	Мне видится, как минимум, два варианта в моем, сравнительно, простом случае: 1.В одном справочнике наименования объектов, в другом наименования статей затрат, в третьем цифры, т.е. значения статей затрат. Чтобы что-то делать мне нужно будет создавать виртуальтную таблицу и с помощью языка запросов получать выборки и уже с ними работать. 2.Все данные в одном большом табличном документе и в нем ищутся строки с нужными объектами и статьями затрат, а из столбцов берутся цифры. Вопрос, собственно, какой из вариантов будет работать у пользователя быстрее ? 0

@Xomych 857 / 656 / 111 Регистрация: 01.11.2012 Сообщений: 2,411
	22.03.2013, 15:49	8
	А как в эту таблицу данные попадают? 0

@Dethmontt Модератор 3784 / 2964 / 589 Регистрация: 10.03.2011 Сообщений: 11,669 Записей в блоге: 1
	22.03.2013, 16:22	9
	первый вариант Сообщение от BVladimir2 1.В одном справочнике наименования объектов, в другом наименования статей затрат, ~~в третьем цифры~~, т.е. значения статей затрат. Чтобы что-то делать мне нужно будет создавать виртуальтную таблицу и с помощью языка запросов получать выборки и уже с ними работать. Кроме этого: Сообщение от BVladimir2 в третьем цифры, Цифры в регистре 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	23.03.2013, 12:22	10
	Сообщение от BVladimir2 2.Все данные в одном большом табличном документе и в нем ищутся строки с нужными объектами и статьями затрат, а из столбцов берутся цифры. это Вы просто так по клавишам стучали. Конфигурация - это модель реальности. Естественно, объекты строительства и статьи затрат в одной куче лежать не могут. Я ещё раз хочу дать совет: продумайте алгоритм прежде чем сформируете структуру. Нарисуйте на бумажке, если в голове не помещается. 0

	27.03.2013, 17:57

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
	26.03.2013, 13:28 [ТС]	11
	Сообщение от duk337 это Вы просто так по клавишам стучали. Конфигурация - это модель реальности. Естественно, объекты строительства и статьи затрат в одной куче лежать не могут. Я ещё раз хочу дать совет: продумайте алгоритм прежде чем сформируете структуру. Нарисуйте на бумажке, если в голове не помещается. Да как раз-то с алгоритмом все более ли менее ясно - простой он сравнительно. Мне не нужно писать большую конфигурацию - речь об отдельной задаче, т.е., по сути, замене Эксэла. Насколько я читал про платформу 1С, она все равно при создании виртуальных таблиц делает что-то типа табличного документа в памяти. И отсюда и возник вопрос- что быстрее работать будет платформенная вирт.таблица или обращение таб.документу... 0

@delphi_Int null 56 / 50 / 13 Регистрация: 06.11.2012 Сообщений: 418
	26.03.2013, 20:30	12
	По ограничениям 1С Вы не можете иметь более 10 000 строк в Таб. Части Документа ! Но даже если у Вас их будет 9 990, Вы хоть представляете сколько по времени он будет Открываться/Записываться (что ещё дольше). Даже если все будет на оптимуме, это будет Самый Самый Самый СамыйСамый СамыйСамый СамыйСамый СамыйСамый СамыйСамый тугой Документ в1С 1

@Xomych 857 / 656 / 111 Регистрация: 01.11.2012 Сообщений: 2,411
	27.03.2013, 10:10	13
	Сообщение от delphi_Int По ограничениям 1С Вы не можете иметь более 10 000 строк в Таб. Части Документа ! Но даже если у Вас их будет 9 990, Вы хоть представляете сколько по времени он будет Открываться/Записываться (что ещё дольше). Даже если все будет на оптимуме, это будет Самый Самый Самый СамыйСамый СамыйСамый СамыйСамый СамыйСамый СамыйСамый тугой Документ в1С На самом деле это не так У меня есть документы >10тыщ строк и они работают и нормально открываются и проводятся 0

@duk337
	27.03.2013, 10:13 #14
	Не по теме: "ах, это, братцы, не о том...":no: 0

@Xomych 857 / 656 / 111 Регистрация: 01.11.2012 Сообщений: 2,411
	27.03.2013, 10:16	15
	Сообщение от BVladimir2 Да как раз-то с алгоритмом все более ли менее ясно - простой он сравнительно. Мне не нужно писать большую конфигурацию - речь об отдельной задаче, т.е., по сути, замене Эксэла. Насколько я читал про платформу 1С, она все равно при создании виртуальных таблиц делает что-то типа табличного документа в памяти. И отсюда и возник вопрос- что быстрее работать будет платформенная вирт.таблица или обращение таб.документу... А почему бы не использовать SQL таблицу? Быстро, надежно, большие объемы данных можно хранить. 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	27.03.2013, 10:20	16
	Вы о чём, ребята? Прежде всего - какие функции должна выполнять эта "таблица", как актуализируется, что там хранится, что вычисляется, как её показывать оптимальнее... Это первое, что в голову приходит, а на самом деле там воз алгоритмических граблей. Кто мешает попробовать десяток вариантов? Дело-то минутное 0

@BVladimir2 17 / 17 / 0 Регистрация: 26.02.2013 Сообщений: 497
	27.03.2013, 10:40 [ТС]	17
	Ну SQL это доп.работа все усложняющая, а мне нужна скорее альтернатива Эксэлу... А кстати, не по теме, "из SQL" данные в 1С можно передавать через ODBC, как я понимаю. Но вопрос в том, сильно ли будет тормозить 1С если данные будут обновлятся несколько раз в секунду (например, бирж.котировки) ? Вообще реально ли использовать платформу 1С для получения данных с биржи, скажем через Quik, и последующую их регистрацию в базе данных ? 0

@Xomych 857 / 656 / 111 Регистрация: 01.11.2012 Сообщений: 2,411
	27.03.2013, 10:51	18
	Сообщение от BVladimir2 Ну SQL это доп.работа все усложняющая, а мне нужна скорее альтернатива Эксэлу... А кстати, не по теме, "из SQL" данные в 1С можно передавать через ODBC, как я понимаю. Но вопрос в том, сильно ли будет тормозить 1С если данные будут обновлятся несколько раз в секунду (например, бирж.котировки) ? Вообще реально ли использовать платформу 1С для получения данных с биржи, скажем через Quik, и последующую их регистрацию в базе данных ? Я работаю с SQL напрямую из 1С, конечно таблицы у меня не 500тыщ записей, а поменьше чуток. У меня написана система онлайн-остатков, т.е. идут продажи с касс, пишутся в эту таблицу, а я их оттуда забираю в 1С. Из 1С можно писать прямые запросы к SQL таблицам через ADO, что работает очень быстро. Например отчет по продажам за год из таблицы в несколько десятков миллионнов записей в 1С у меня формируется за несколько секунд. 1