|
|
|
help!
|
|||
|---|---|---|---|
|
#18+
Вы все время путаете отображение данных и их хранение. Все Ваши таблицы рассчитаны на то, что они будут отображаться "как есть". Но форма отображения данных крайне неудобна для обработки данных. Причем, в большинстве случаев, сформировать нужный вид для отображения не так уж и сложно из любой формы хранения. Следовательно, Вам необходимо всерьез заняться структурой хранения. Переделать ее таким образом, чтобы можно было удобно и быстро ее обрабатывать. Скорость отображения в нужной форме должна быть на втором плане. Достаточно только иметь информацию для такого отображения. Ну, например, если рассматривать лотерейный билет спортлото, то это набор ячеек. Вместо того, чтобы пытаться хранить данные "как есть", т.е. столбцы - это поля, а строки - это записи, надо представить каждую ячейку как набор 3 значений - Номер строки, Номер столбца, Значение. Плюс добавить номер карточки. В результате приходим к структуре таблицы из 4 полей. Обрабатывать такую структуру достаточно просто. Первести ее в форму для отображения тоже не представляет труда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 17:45:27 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Создаётся впечатление, что эту задачу нужно НАМ решать а не тебе, просто клещами информацию приходится вытаскивать! 1) Неверная постановка задачи ведёт к заведомо неверному результату. 2) Правила, которым удовлетворяют комбинации ты так и не написал. Хорошо, предположим что это правила руссколо лото. 3) Структура таблиц для АНАЛИЗА выбрана не совсем удачно. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 02:56:05 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Ya pitalsa snachala xranit dannie 'kak yest'. No, seychas,dlya xranenie dannix ya ispolzuyu bazk.dbf, a dlya otobrajenie bask1.dbf. To test, (pravila, kotoriy udovletvoryaet kombinatsii: u menya v kajdom kartochke 3 stroka i 5 stolbets, a chisla rassortirovani po kolonkam v zavisimosti ot tovo k kakomu desyatku oni prinadlejit. Vsevo v kajdom kartochke 10 chislo. Iz nix 5 v verxnim 2 stroke, 5 v nijnim (poslednim) stroke naxoditsa. No, dlya raboti proqrammi iz etoy tablitsu (bask1.dbf) poluchayu noviy -bask.dbf. (vmesto 3-x zapisey 1 zapis) Ya dumal chto tak bistree budet rabotat. VladimirM, yesli ya budu izmenyat strukturu tablitsu kak Vi qovorite, eto znachit ya vsyo proqrammu doljen menyat. No ya seychas budu ob etom dumat kak eti '4 pole' obrobatovat. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 08:41:45 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Salam.Sen Bizim dilde yaz gorum ne etmek isteyirsen? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 13:48:12 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Не уверен что правильно понял... Т.е. в карточке 15 полей (3*5) но заполнено из них лишь 10. 5 в первых двух строках и 5 в последней (т.е. последняя строка заполнена полностью)? В столбцах содержатся числа из соответствующего десятка - т.е. в первом из первого, в пятом - из пятого. Не ясно могут ли в одной карточке повторяться числа? Если я понял между 1 и 2 строками повторений нет, а вот как насчёт между всеми 3-мя строками? Опять же не понятно зачем тебе при розыгрыше анализировать "повторения", или ты просто для уточнения (и создания алгоритма генерации тестовой базы) это сказал, а реально никаких повторений не будет - т.е. в ходе игры это проверять уже не надо? Как я понимаю 2 первые строки не для красоты сделаны, а для того, чтобы можно было в одной карточке иметь 2 значения из одного десятка? Т.е. в первых двух строках могут быть пустые колонки (скажем есть числа 1 и 2, но нету ни одного числа из 2-й десятки)... Также не понятно это опечатка насчёт диапазона первой колонки (от 1 до 9) или реально число 10 попадает во 2-ю колонку? Ибо получается дисбаланс - в первой колонке возможно 9 чисел, во второй 11, в остальных по 10... Сколько всего может быть билетов (вообще ограничено их число ВСЕГДА или нет - скажем тираж 20Млн и не больше)? Кстати говоря, в 3-й строке при таких условиях возможны всего 100 000 комбинаций, а в первых двух строках - всего 4 330 000 комбинаций - т.е. задачу можно разбить - предварительно каждому из твоих 20 млн "билетов" сопоставить 2 цифры - номера соответствующих комбинаций и искать уже через посредство сравнительно небольших таблиц - но надо посмотреть поможет ли такое "разбиение" ускорить процесс. Также важно знать насколько критично время поиска выигрышных билетов - т.е. это OnLine розыгрыш и нужно после каждого хода объявлять что столько-то билетов выиграло и такой-то их выигрыш, или Offline - и скорость некритична. Теперь насчёт алгоритма проверки - что и как проверяется. Как я понял "выигрыш" - это если "закрыты" полностью первые 2 строки ИЛИ закрыта полностью третья строка? 1-й тур: До каких пор идёт игра? До появления первого выигрыша, или какое-то фиксированное число ходов? Нужно просто найти все выигравшие или тут важно на каком ходе они выиграли? Важен НОМЕР хода, или просто СКОЛЬКО билетов выиграло на N-м ходу (ну чтобы разделить между ними часть призового фонда поровну, тогда как собственно размер этой части от хода не зависит). Про 2-й тур (и возможно последующие) вообще ничего не сказано... Я для теста создал несколько другую структуру: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. нижняя полная строка) и cValue - собственно значение находящееся в ячейке, "завернутое" в ASCII символ. Порядок следования значений не играет никакой роли. Создаются 2Млн записей примерно 6 минут (ну и ещё минуты 4-5 индексируются). В итоге получаем таблицу в 140Мб и индекс под 200Мб. "Розыгрыш" выполняет следующий код (можно и эффективнее сделать - например как в варианте заполнения - создать массив из 50 элементов, и на каждом ходу "вынимать" оттуда один элемент - естественно удаляя его из массива, и уменьшая его размер): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Поиск выигрышного билета занимает (напомню, что база 2Млн билетов) примерно по 1-2 минуте на ход (это пока мне не надоело ждать - т.е. первые ходов 10 - чем дальше тем медленнее, т.к. уже результатная выборка становится чересчур велика). Можно придумать и другие алгоритмы поиска... Можно для эффективности признак "выбивания" числа сделать отдельным полем, и создать по нему BINARY индекс (в VFP9) - индекс заметно уменьшится, правда сама таблица "подрастёт" на 15%... Кстати используемую версию фокса я тоже не увидел нигде - это важно... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 04:42:18 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Privet, Igor Korolyov! V obshem Vi vse provilno ponyali. Seychas ya poprobuyu otvetit na ostalnie voprosi. 1.V odnoy kartochke (vo vsex 3-x strokax) ne doljno povtoryatsa chislo. 2. Pri roziqrishe alqoritmov 'povtoreniya' ne nujen. V xode iqri eto proveryat uje ne nado. 3. Naschet diapazona: 1-ya kalonka- ot 1 do 9 2-ya kalonka- ot 10 do 19 3-ya kalonka- ot 20 do 29 4-ya kalonka- ot 30 do 39 5-ya kalonka- ot 40 do 50 4. Tiraj mojet bit i menshe 20 mln ili bolshe 20 mln Konkretno kloichestvo biletov netu. 5. Vremya viqrivshnix biletov -ochen vajno To yest, ya delal proqrammu uje rabotayushiy s 400000 zapisyami vremya 5-7 sek. No uje bolshimi kolichestvami mojno skazat ne rabotaet. Eto online roziqrish, i nujno posle kajdovo xoda obyavlyat chto skolko-to biletov viqrala, i takoyto ix viqrish, v kokom xode viqrala. 5. I tur zakanchivaetsa toqda, koqda 'zakrita' polnostyu pervie 2 stroka, ili zakrita polnostyu 3-ya stroka. (Do poyavlenie 1-vo viqrisha) 6. II tur zakanchivaetsa toqda koqda polnostyu zakrita xotyabi odno kortichka. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 07:53:39 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Privet, Igor Korolyov! Sposibo, za Vash takoy podrobniy otvet! Seychas ya analiziroval napisanniy Vami kod. No delo v tom chto, moya proqramma mojno skazat , chto uje qotovo (no, skorost ne raduet s takimi bolshimi tablitsami), i ya ne xocu seychas vsyo izmenit (struktura tablitsu i t.d.), i na eto vremya netu. Poetomo ,poka postarayus, kak nibud vsyo ostovlyaya kak yest, "uskorit" vipolnenie proqrammi. No, privedyonniy Komissara primer zapolnenie tablitsu rabotaet bistree, no, na obrabotku ochen mnoqo vremya zanimaet . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2005, 16:55:57 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Извини, дружище! Хотел попробовать придумать алгоритм обработки, но получился небольшой аврал по работе... Еще и жена вчера ногу слегка сломала... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2005, 20:57:50 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Пока не могу ничем обнадёжить - мой вариант не будет работать выстрее, и вообще я сильно сомневаюсь что силами одного лишь фокса можно сделать ПРИЕМЛЕМЫЙ по скорости вариант для такого большого массива. Мой код заполнения сейчас практически аналогичен тому что Komissar написал (ну только с добавлением твоей 3-й строки карточки), и тем не менее 20Млн записей создавались в течении 78 минут (больше часа). Я попробовал (слегка изменив) твою структуру - получается что на ход затрачивается от 210 до 350 секунд (по мере роста числа "выигравших" билетов происходит существенное замедление - оно и понятно - вынуть 14 записей и поместить их в курсор это одно, а вынуть все 20Млн записей - это уже совсем другое :( ) Единственно чего я не учитывал - так это странностей распределения чисел в твоей схеме - даже по последним приведенным данным выходит, что в первой группе (первой колонке) всего 9 возможных значений, во 2, 3 и 4 по 10, а в 5-й 11... Просто лень под это закладываться, да и для результата это некритично. вот что критично - так это объём файла. У тебя (и у Komissar тоже) структура избыточна! ДАЖЕ если хранить числа в "полном" виде, то они запросто влазят в поле C(1)! Я же и вовсе пошел дальше, и сохранил лишь младший разряд от числа - т.к. старший разряд однозначно определяется номером колонки (с учётом конечно вышеописанного мной "упрощения"). Можно хранить и полное число, завернув его через CHR() в один символ. Также номер карточки стоит хранить в поле типа Integer (занимает всего 4 байта вместо тех 8 что выделил ты). Итого получаем экономию в 2 раза!!! Recsize() всего 20 байт - т.е. теоретически можно дойти до более чем 100Млн карточек. Твои служебные поля скорее всего не помогут в деле ускорения процесса - как я понимаю что анализ на этапе Update, что анализ позже - разницы нету, а вот dbf становится больше от этого... Кстати на 200 тысячах карточек алгоритм отрабатывает примерно за 1.7 секунды на ход (а заполнение таблицы занимает чуть менее 50 секунд) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. условия для второго тура). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. заполнения) в EXCLUSIVE - это должно дать выигрыш в скорости. Также используется REPLACE, поскольку он для массовой замены в монопольно открытой таблице будет быстрее чем UPDATE. Как замечание - для столь большой таблицы ОЧЕНЬ много времени тратится на файловые операции, индексы по всем полям тут вряд-ли помогут (в тесте по 200000 таблице они дали замедление - ход просчитывался около 2.2 секунд) - они во-первых занимают раза в 2 больше места чем сам dbf, и во-вторых (что наверное важнее всего) - они очень мало "распределенные" в рамках одного поля мы имеем всего 11 (или 10 для b* полей) возможных значений - т.е. тут получается та-же беда что и с индексом по Deleted()... В общем есть такое предположение, что для приемлемой скорости данную процедуру нужно писать на C, а ещё лучше на ASM - и не с таблицей работать, а непосредственно с памятью (если нормально "упаковать" данные, то одно число из карточки будет занимать всего 1 байт - т.е. на твои 20Млн карточек потребуется всего чуть менее 200 Мб - т.е. на нормальном современном компе это вполне реально - главное чтобы эта память в своп не выпадала!). Конечно сравнительно большое время займёт "загрузка" данных из таблицы в память, но зато потом обработка будет проходить очень быстро... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 03:39:13 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Мдя... Пока отсутствовал - отстал от темы... :( Вставлю таки свои 5 коп. насчет формирования таблицы - не надо RAND()! Тормозит ведь мрачно! 3-ий вариант!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 13:14:35 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Privet,Komissar! Jelayu Vam i vashey jene zdorovye. Vashi varianti dlya formirovanie tablitsu ustraivaet menya. 20 mln. zapisey ne tak dolqo sformirovalsa,pravda seychas ne pomnyu skolko. (uchitivaya, cho eto odnorazoviy proses).. No, obrabotka nad etoy tablitsoy s moimi proqrammami ochen dolqo idyot, primerno 3 mln. zapis -za 8-9 minut. A eto online roziqrish, i mne nado za korotkiy srok obyavit 1) vishedshiy nomer, 2) skolko biletov viqrala, 3) i kajdiy bilet skolko viqrala. Mne Igor Korolyov sovetoval chto, s takimi bolshimi razmerami lucshe rabotat na C, ili asm. No ya rabotal na Delphi i Nemnojka Na Foxpro. V delphieto- yeshyo slojnee (nascet vremeni). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 14:19:41 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Я тут попросил коллегу нарисовать код на C#, возможно попробую на чистом C тоже сделать - посмотрим как оно будет по скорости... 2 Komissar 1) Ты не учитываешь второй части карточки - с этим получится заметно сложнее. 2) 51 подобный "блок" рисовать - как-то напряжно :( Конечно можно и по другому попробовать. 3) Всё зависит от того какое "распределение" допустимо. Если "последовательное" нормально - то конечно так, если же нет - то без RAND() не обойтись. Хотя можно его вынести в другую часть - номера билетов им генерить, а само "содержимое" каким-то последовательным методом (аналогичным твоему). Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2005, 20:54:35 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov1) Ты не учитываешь второй части карточки - с этим получится заметно сложнее. 2) 51 подобный "блок" рисовать - как-то напряжно :( Конечно можно и по другому попробовать. 3) Всё зависит от того какое "распределение" допустимо. Если "последовательное" нормально - то конечно так, если же нет - то без RAND() не обойтись. Хотя можно его вынести в другую часть - номера билетов им генерить, а само "содержимое" каким-то последовательным методом аналогичным твоему). Привет, Игорь! 1. Поначалу разговора о второй части не было... 2. Вот и я сильно ограничился в примере... 100% можно придумать "автоматизацию", но ведь оно одноразовое... 3. Именно! Сгенерить последовательно, а потом "перетасовать"... Впрочем, вопрос формирования уже не актуален... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2005, 12:08:57 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Код на C# обрабатывает 20Млн карточек за время от 2 до 10 секунд (в зависимости от того сколько уже чисел "выпало" - поскольку сам массив НЕ изменяется, просто каждый элемент проверяется на наличие в другом массиве - "выигрышных" номеров - операция записи в память, как я понял, оказывается "дороже" нескольких операций чтения и сравнения). Поскольку в твоём случае с очень большой вероятностью первый тур закончится на 5-м ходу :) то можно считать что время "отклика" составит 2 секунды. P.S. Естественно что на машине ДОЛЖНО быть установлено как минимум 256 Мб памяти (лучше 512 Мб) - иначе прога уйдёт в жестокий своп и считать будет на порядок дольше. P.P.S. Естественно что проверялся САМ ПРИНЦИП - т.е. для C# никто не делал "правильного" генератора - т.е. просто карточки заполнялись 10-ю совершенно случайными числами. Ну и собственно код - он компилируется в консольное Win32 приложение. (Надеюсь индекс i не воспримется за тег в блоке кода). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2005, 00:48:02 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Privet, Igor! Spasibo, Vam za vsyo eto. 2 ili 10 sek. za 20 mln. zapis, eto konyeshno ochen xorosho . No, ya pro C# nichevo neznayu, i seychas kak proverit etot kod neznayu. I yeshyo dumayu chto izucat C# za tokoy korotkiy srok - nichevo ne poluchitsa. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2005, 09:04:54 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Hi SDF! Ну тут я ничем помочь не могу уж. В принципе всё то-же самое можно на чистом C сделать, скомпилировать в dll/fll и пользовать из фокса... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2005, 01:03:36 |
|
||
|
help!
|
|||
|---|---|---|---|
|
#18+
Ya ponyal chto imenno eto chast proqrammi ochen dolqo rabotaet. No kak eto chast proqrammi ili voobshi alqoritm mojno optimizirovat (ne silno menyaya strukturu tablitsu)- nicevo ne nashel. lnValue - Vishel kakoy-to nomer. 1. Proveryayu etot nomer kakoy diapozon vxodit. 2. Obnulyayu vse eti znachenie yesli yest takaya 3. Proveryayu summa znachenie vsex poley 'AA' (sum_a=AA1+AA2+....AA14) Yesli eto summa =0 toqda 1-y tur zakanchivaetsa. if lnValue<=9 update bask set aa1 = 0 where aa1 = m.lnValue update bask set aa8 = 0 where aa8 = m.lnValue update bask set bb1 = 0 where bb1 = m.lnValue endi if lnValue>=10.and.lnValue<=19 update bask set aa2 = 0 where aa2 = m.lnValue update bask set aa9 = 0 where aa9 = m.lnValue update bask set bb2 = 0 where bb2 = m.lnValue end .... .... .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2005, 14:47:05 |
|
||
|
|

start [/forum/topic.php?fid=41&gotonew=1&tid=1593344]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
314ms |
get topic data: |
27ms |
get first new msg: |
168ms |
get forum data: |
5ms |
get page messages: |
79ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 879ms |

| 0 / 0 |
