После какого кол-ва строк в списке стоит задуматся о БД?

  • Автор темы Автор темы Mikhail B.
  • Дата начала Дата начала

Mikhail B.

Client
Регистрация
23.12.2014
Сообщения
14 449
Реакции
5 477
Баллы
113
Допустим есть списко в котором 20 значное значение числовое. Я буду раз в 10 сек дописывать туда строку и проверять список на наличие новых строк.
После какого кол-ва строк стоит подумать о БД?

100к
500к
1 млн

Скорость не важна, если будет обрабатываться 1-2 сек, мне все равно.
 
зачем задумываться ? надо сразу осваивать, что бы не пилить дважды одну и туже задачу.
 
  • Спасибо
Реакции: sydoow и one
зачем задумываться ? надо сразу осваивать, что бы не пилить дважды одну и туже задачу.
Нет я придерживаюсь других принципов. Тем более делаю на заказ. Зачем мне поднимать БД, тратить на это время если можно обойтись простым списком. Хотя есть активисты, за правильность кода, я не такой. Через месяц просто сделаю замеры обработки списка, если оно будет в пределах 2 секунд, еб#сь оно на все четыре стороны.
 
Нет я придерживаюсь других принципов. Тем более делаю на заказ. Зачем мне поднимать БД, тратить на это время если можно обойтись простым списком. Хотя есть активисты, за правильность кода, я не такой. Через месяц просто сделаю замеры обработки списка, если оно будет в пределах 2 секунд, еб#сь оно на все четыре стороны.
у меня в одном проекте при списке выше 100к строк , зенка начинает жестко задумываться именно в месте взятия строки из списка. если предполагается что список будет безгранично расти и нет метода на C# для оконного скана файла и работа будет идти через стандартные списки зенки, то только БД. если список ограничен, то можно еще подумать.
 
  • Спасибо
Реакции: Mikhail B.
у меня в одном проекте при списке выше 100к строк , зенка начинает жестко задумываться именно в месте взятия строки из списка. если предполагается что список будет безгранично расти и нет метода на C# для оконного скана файла и работа будет идти через стандартные списки зенки, то только БД. если список ограничен, то можно еще подумать.
Ну будем решать по факту)

Пользуюсь таким снипетом

C#:
Развернуть Свернуть Копировать
IZennoList Names = project.Lists["Blacklist_id"]; //привязываемся к списку
 
lock (SyncObjects.ListSyncer)
{
string Element = project.Variables["ID_mini_blacklist"].Value;
return Names.Contains(Element); // True/False
}
 
Нет я придерживаюсь других принципов. Тем более делаю на заказ. Зачем мне поднимать БД, тратить на это время если можно обойтись простым списком. Хотя есть активисты, за правильность кода, я не такой. Через месяц просто сделаю замеры обработки списка, если оно будет в пределах 2 секунд, еб#сь оно на все четыре стороны.
На сколько я знаю, зависит не от строк, а от объёма.
Так что хрен его знает сколько строк вам нужно, что бы перейти на б.д
 
  • Спасибо
Реакции: Mikhail B.
ну это стандартный метод зенки. при больших объемах запросто непонятка будет.
лучше поискать код C# для поиска нужной строки через оконное считывание без загрузки в память. видел на каком то форуме по c# , но не помню уже где.
 
ну это стандартный метод зенки. при больших объемах запросто непонятка будет.
лучше поискать код C# для поиска нужной строки через оконное считывание без загрузки в память. видел на каком то форуме по c# , но не помню уже где.
А что плохого если список в памяти?
 
А что плохого если список в памяти?
по идее ничего плохого, но большой список не сможет прогрузиться быстро.
это для однопотока. а в многопотоке зенка не очень хорошо работает со списками.
не тут дело лично конечно, лично я намучался со списками и выбросил их из проектов. у меня там даже до 100к строк не доходило. то пропадают все строки, то путаются, то память раздувается....
перешел на SQLite как замену мелким спискам и норм. правда она вообще не подходит для жесткого многопотока, но вот нормальная база должна нормально работать в этом плане.
 
Спрошу если автор не против ( нет перенесу в чат/отдельную тему)
Раз уж тут о базах и списках - посоветуйте ,пжлста решение ( на какую базу перейти со списков ?) для серверов/пк в одной локальной сети . Сейчас использую "расшареные" папки / сетевые диски. Ну и в догонку - есть ли удачный опыт и можно ,стоит ли ,использовать под это(базы) ресурсы Яндекс диска?
 
Спрошу если автор не против ( нет перенесу в чат/отдельную тему)
Раз уж тут о базах и списках - посоветуйте ,пжлста решение ( на какую базу перейти со списков ?) для серверов/пк в одной локальной сети . Сейчас использую "расшареные" папки / сетевые диски. Ну и в догонку - есть ли удачный опыт и можно ,стоит ли ,использовать под это(базы) ресурсы Яндекс диска?
Я ставил phpMyAdmin для MySql, на серверную Windows, ставится за пол-часа максимум, по инструкции: Установка и настройка phpMyAdmin на IIS в Windows Server
Потом можно открыть доступ для отдельных IP или для всех
 
  • Спасибо
Реакции: sergio197675
по идее ничего плохого, но большой список не сможет прогрузиться быстро.
это для однопотока. а в многопотоке зенка не очень хорошо работает со списками.
не тут дело лично конечно, лично я намучался со списками и выбросил их из проектов. у меня там даже до 100к строк не доходило. то пропадают все строки, то путаются, то память раздувается....
перешел на SQLite как замену мелким спискам и норм. правда она вообще не подходит для жесткого многопотока, но вот нормальная база должна нормально работать в этом плане.
Там как раз однопоток будет)

Спрошу если автор не против ( нет перенесу в чат/отдельную тему)
Раз уж тут о базах и списках - посоветуйте ,пжлста решение ( на какую базу перейти со списков ?) для серверов/пк в одной локальной сети . Сейчас использую "расшареные" папки / сетевые диски. Ну и в догонку - есть ли удачный опыт и можно ,стоит ли ,использовать под это(базы) ресурсы Яндекс диска?
Если лень. Можно просто опен сервер накатить. Там есть мускул.
 
  • Спасибо
Реакции: sergio197675
Я вообще с тхт и таблицами перестал работать. На очень быстрых запросах, или строки пропадают или битые строки, сравнивал отдельно с бд. Ну про скорость уже не будем, и так понятно. Разбивал запись и по папкам с файлами, например 100 папок и в каждом по 100 файлов, до задницы. В бд надежней и быстрее. Объемы от КК (000 000) до нескольких ККК (000 000 000). Если я правильно трактую К.
 
Как по мне дак одного только факта что при нештатном выключении ZP во время работы шаблона может тупо пропасть пол списка - это уже железобетонный аргумент за переход на БД. Это я не говорю да же про скорость и удобство получения данных (язык SQL иногда может заменить тонну кода при работе с обычным списком)
 
  • Спасибо
Реакции: Wide
А стоит галка безопасно сохранять файл в настройках зенно?
Естественно. Я говорю как есть, выдумывать ни к чему. Как отловить не знаю, специально написал шаблон для сравнения количества строк в файлах и бд, разница всегда была. В зп боль списки и таблицы, причем как заметил тхт более стабилен, но с бд не сравниться.
 
  • Спасибо
Реакции: Mikhail B.
Как по мне дак одного только факта что при нештатном выключении ZP во время работы шаблона может тупо пропасть пол списка - это уже железобетонный аргумент за переход на БД. Это я не говорю да же про скорость и удобство получения данных (язык SQL иногда может заменить тонну кода при работе с обычным списком)
После первого краша списка научился работать с БД)
 
  • Спасибо
Реакции: WebBot
Я бы не задумывался таким вопросом а стал бы работать с БД. Уже двно это обдумывали здесь, на форуме и все, кто преходил в итогде на БД пИсали кипятком, я в том числе.
 
Последнее редактирование:
  • Спасибо
Реакции: WebBot
Я бы не задумывался таким вопросом а стал бы работать с БД. Уже двно это обдумывали здесь, на форуме и все, кто преходил в итогде на БД пИсали кипятком, я в том числе.
И есть от чего кстати) Достаточно посмотреть на скорость нужно ли говорить что такое со списками в далеком будущем зп не светит. Эту же задачу на списках без ошибок записи и пр. на списках так и не получилось реализовать.
 

Кто просматривает тему: (Всего: 0, Пользователи: 0, Гости: 0)