Как лучше сделать кассовую программу-склад на PHP?

Как-то от примитивной программы тема свалилась в HiLoad.
Я лично видел MySQL на нагруженных проектах - прекрасно работает. Может вы просто не умеете его готовить?

Прошу прощения, что Вы считаете нагруженными проектами? И какое серверное оборудование убито на функционирование этого MySQL сервера? И вообще, больше чем уверен - скорее всего все обстояло примерно так, как описал Tores - тоесть в момент написания проекта недальновидный разработчик выбрал СУБД MySQL потому, что ничего другого не знал и выучить был не способен проанализировал существующие СУБД и счел, что MySQL отлично подходит для решения данных задач, так как она бесплатная и на ней все пишут. По началу проект не был высоконагруженным и все было отлично... Потом нагрузили, и посчитали что докупить в сервер еще процессоров и планок памяти оказывается дешевле чем нанять уже нормальных программистов и переписать все с нуля, поскольку первый разработчик свой гонорар уже получил и потратил...
Цитата ("Demiurh"):

Может вы просто не умеете его готовить?

А может мы просто более разборчивы?

Цитата ("dervinar"):

Мнения бывают разные, но истина одна.
посилання - это не мое мнение...

Они в этой статье, вообще-то, сравнивают два сервера, а не postgres с mysql: с точки зрения сравнить два сервера - цифры у них вполне убедительные, а вот сравнивать две СУБД по этим цифрам никак нельзя, можно так сконфигурировать mysql, что он будет работать в сотни раз медленнее чем postgress, можно и наоборот - сделать postgress медленнее mysql.

Цитата ("dervinar"):

А еще существует мнение, что самые лучшие сайты в мире пишутся на Php+MySQL и крутятся на веб сервере Apache. Вот только почему-то уважающие себя крупные компании настолько несознательны, что для своих сайтов предполагающих пиковую посещаемость более 2 человека в секунду не используют ни Php ни MySQL.

Два человека в секунду - посещаемость очень и очень невысокая. Я сейчас, шутки ради, измерил пропускную способность одного сайта на моей локальной машине, получилось 21 запросов/сек при подаче 10 запросов одновременно. Сайт написан на perl, работает под Apache (в режиме CGI) и mysql, никакой оптимизации. Если оптимизировать - будет раза в два быстрее, под mod_perl - быстрее раз в 5-6, так что говорить о том, что Апач или там MySQL годятся только для детского сада, на мой взгляд, несколько преждевременно.

И еще пара цифр из практики: пару лет назад лет водил я близкое знакомство с одним сайтом, Apache+PHP+MySQL под FreeBSD, 4 CPU, 4G RAM. Нагрузка на сайт была около миллиона запросов (хитов) в сутки (включая статический контент), поток запросов на MySQL был 45-55 запросов/сек., Апач все время держал 150-180 активных процессов. Код MySQL был совершено любительского уровня (например, функция IN() со списком аргументов в 50 строк по 80 символов в строке). И все это работало приемлемо быстро, 3-4 сек. на страницу.

Цитата ("dervinar"):

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

А Апач разве не серверный демон?

Цитата ("dervinar"):

Крайне странно, с чего бы это, не находите?

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

Про 1С 8.2 с веб интерфейсом не думали ???

Цитата ("Illarion_SA"):

Я сейчас, шутки ради, измерил пропускную способность одного сайта на моей локальной машине, получилось 21 запросов/сек при подаче 10 запросов одновременно. Сайт написан на perl, работает под Apache (в режиме CGI) и mysql, никакой оптимизации. Если оптимизировать - будет раза в два быстрее, под mod_perl - быстрее раз в 5-6, так что говорить о том, что Апач или там MySQL годятся только для детского сада, на мой взгляд, несколько преждевременно.

Ну perl и пхп вещи все таки разные. И я не говорил, что Апач годится только для детского сада. Нет не для детского. Уверенный средний уровень.

Цитата ("Illarion_SA"):

И еще пара цифр из практики: пару лет назад лет водил я близкое знакомство с одним сайтом, Apache+PHP+MySQL под FreeBSD, 4 CPU, 4G RAM. Нагрузка на сайт была около миллиона запросов (хитов) в сутки (включая статический контент), поток запросов на MySQL был 45-55 запросов/сек., Апач все время держал 150-180 активных процессов. Код MySQL был совершено любительского уровня (например, функция IN() со списком аргументов в 50 строк по 80 символов в строке). И все это работало приемлемо быстро, 3-4 сек. на страницу.

3-4 секунды, имхо, результат далекий от приемлемого, к тому же для мощной машины. Или Вы станете утверждать, что будучи переписанный(даже с той же степенью "оптимизации" и такими же нелепыми запросами) на D и с базой данных PostgreSQL оно не станет работать быстрее и меньше грузить сервер?

Цитата ("Illarion_SA"):

А Апач разве не серверный демон?

А Апач разве сайт? Речь шла о сайтах, которые висят в памяти постоянно, неспосредственно читают с сокета, генерируют ответ, пишут в сокет и не запускают никаких процессов. Апач же все делает сам, потом запускает отдельный процесс скрипта (грузит его в ОЗУ, перл еще и компилирует, скрипт подключается к бд читает файл с шаблоном, потом пишет в поток и умирает).

В общем, я не говорю, что нельзя использовать php+mysql. Можно. Но это будет всегда хуже. А на больших нагрузках еще и дороже. Хотябы по памяти. 150-180 активных процессов - это сколько в мегабайтах? А их еще каждый раз подгружать надо. Вот и считайте.

Цитата ("Illarion_SA"):

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

Ну да, все так и было=) Парни, которые "страдают такой херней", как написание серверных демонов постоянно пропадают и не оставляют своего адреса - действительно, зачем, вдруг благодарные клиенты еще клиентов приведут.. Ужас просто.
И, соответственно, есть талантливые Php - программисты, которые может быть и знают что такое переменные окружения и как к ним обращаться, но вот откуда эти таинственные переменные окружения берутся и как они вычисляют, какой браузер использует пользователь, даже не догадываются... И вот эти талантливые Php программисты всегда оставляют свои адреса, телефона, номера паспортов и еще кровью расписываются. Потому как клиентов любят...
И еще более правильно, что такой сайт надо как можно быстрее переписать на Php и MySQL - вот только одна проблема, дорого. На одних серверах разоришься - то, что отлично держалось на 1 сервере придется на 3 более мощных разносить... Приходится поддерживать...

После долгих слушаний и мыслей, я такой вывод вывел...Поправьте меня, если я где неправ...
Если нужна кассовая программа для магазина где покупателей... ну скажем не так много в течение дня или разом - то Web вариант на PHP c MySql будет для - не очень богатого на финансы магазина такой скажем бюджетный вариант.
Цитата ("chromotron"):

вот только как раз никак не С, просто неоправданно по трудозатратам и деньгам

Если я ничего не путаю, чтоб не очень сильно затрачиваться, то первый вариант вполне пойдёт или на MySQL или на PostgreSQL, ну как я и думал обязательно с Ajax...

Если же посещаемость покупателей ожидается ну скажем 10000 или в разы больше, то этот вариант не подойдёт, по причине отставания перед проектами на Oracle и "иже с ним" - не в обиду будет сказано...

Цитата ("ArtPro"):

Про 1С 8.2 с веб интерфейсом не думали ???

Я смотрел много всяких вариантов, 1С тем паче, перед тем как тему создавать. После этого поста решил ещё раз пересмотреть. Но если я не дурак, то, как я понял, 1С.Web расширение подразумевает установленный - 1С.Предприятие, а это уже консоль... это уже означает. один компьютер с ним (1С.Пред) и каким-то образом остальные к нему связанные. Независимо машины с установленной базой нельзя использовать : не нарушая лицензионность программы. (проблема не "в возможности установки просто так", а в правовой стороне - что очень важно). А это самая основная причина надобности в таком продукте, который ставь куда хочешь и сам как хочешь.И ещё...1С.Предприятие, даже если не думать о несвязанных компах, в свою очередь требует Windows Server - это опять ещё лицензия..
Если даже взять 1C по дистрибюторским ценам разница очень даже...всё равно от консольности и единовариантности (1 лиценизия - 1 установка) не уйти никуда...
Если "дай бог" вдруг дела пойдут, захочешь что-то ещё сделать, то опять лицензия и опять всё остальное...

Поправьте меня, если что не так...........

Цитата ("tores"):

.И ещё...1С.Предприятие, даже если не думать о несвязанных компах, в свою очередь требует Windows Server - это опять ещё лицензия..

под linux отличненько работает

Цитата ("tores"):

Если "дай бог" вдруг дела пойдут, захочешь что-то ещё сделать, то опять лицензия и опять всё остальное...

скажу по секрету. не платите за ИТС ни копейки, а просто наймите своего программера приходящего.

Цитата ("tores"):

1С.Web расширение подразумевает установленный - 1С.Предприятие

немного не так... в 8,2 версии на стороне клиента есть почти полноценный веб нтерфейс.. изврат, но получается 1С и битрикс совмещен как бы

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

Цитата ("dervinar"):

Апач же все делает сам, потом запускает отдельный процесс скрипта (грузит его в ОЗУ, перл еще и компилирует, скрипт подключается к бд читает файл с шаблоном, потом пишет в поток и умирает).

mod_perl + Persistent Database Connections, например c Apache:: DBI

PS. Может все же не умеете?

По теме и автору: кроме добавлений, уже сделанных ArtPro касательно 1с - поправлять Вас в общем то не в чем.

Цитата ("dervinar"):

лучше уж длиной провода от мышки меряться.

Насчёт длины провода от мышки, это мне понравилось. Y меня покупатели игрушек - "игроки" меряются уже не пройденными уровнями, а сколько окон одновременно они могут запускать и играть скажем в какой нибудь Lineage2, или типа того...
А вот прогеры обычно по магазам не ходят, они всё по инету покупают... Теперь знаю, что они длиной провода мышки меряются.....

Цитата ("dervinar"):

Ну perl и пхп вещи все таки разные. И я не говорил, что Апач годится только для детского сада. Нет не для детского. Уверенный средний уровень.

В режиме CGI (а именно в этом режиме я и получил 21 запрос/сек), производительность perl и php примерно одинаковая, ну может быть отличается процентов на 50, но не в "разы".

Цитата ("dervinar"):

3-4 секунды, имхо, результат далекий от приемлемого, к тому же для мощной машины.

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

Цитата ("dervinar"):

Или Вы станете утверждать, что будучи переписанный(даже с той же степенью "оптимизации" и такими же нелепыми запросами) на D и с базой данных PostgreSQL оно не станет работать быстрее и меньше грузить сервер?

Трудно сказать не имея переписанного на D+Postgres сайта и не измерив его пропускную способность. Но я не удивился бы, если бы переписанный сайт стал работать медленнее и менее устойчиво. Причиной этого может быть, например, то что программу на D нельзя оформить в виде модуля Апача или то, что Postgres на FreeBSD работает медленне чем MySQL.

Цитата ("dervinar"):

А Апач разве сайт? Речь шла о сайтах, которые висят в памяти постоянно, неспосредственно читают с сокета, генерируют ответ, пишут в сокет и не запускают никаких процессов. Апач же все делает сам, потом запускает отдельный процесс скрипта (грузит его в ОЗУ, перл еще и компилирует, скрипт подключается к бд читает файл с шаблоном, потом пишет в поток и умирает).

Это Вы описали схему работы Апача в режиме CGI (или CGI-script). Если скрипты сайта работают под mod_perl (или mod_php или FastCGI), то обработка запроса строится примерно так, как Вы написали ранее, т.е. процессы сайта постоянно висят в памяти, читают/пишут в сокет, ведущий процесс Апача передает им сокеты (в виде дескрипторов файлов), при необходимости запускает дополнительные обработчики или "убивает" те у которых вышел срок жизни. Если еще при этом скрипты сайта держат открытыми соединения с базой данных (например модулем Apache-DBI или своими средствами), то все это работает раз в 10-20 быстрее чем в режиме CGI-script.

Разумеется, за все приходится платить и, например, процессы Apache-mod_perl на 64-хразрядной системе занимают по 120-150М на процесс, а постоянно висящие в памяти процессы требуют высокой дисциплины программирования, но память нынче стоит дешевле чем программисты, а дисциплина программирования еще никому не мешала.

Постоянно открытые соединения с базой данных тоже чреваты неожиданными эффектами: например, тестируя тут одну программку я обнаружил что pgbouncer стабильно "забывает" про открытое соединение если в течении трех часов по нему не передавалось никаких данных. А сам сервер postgreSQL про такие соединения забывает только через 9 часов неактивности, да и то не всегда

Цитата ("dervinar"):

В общем, я не говорю, что нельзя использовать php+mysql. Можно. Но это будет всегда хуже.

Здесь нельзя говорить "всегда". Для каких-то задач, например, для магазина с которого началась эта тема, php+mysql будет лучше исходя из стоимости разработки и стоимости дальнейшего сопровождения - здесь разница в стоимости может быть в 10-100 раз. Для одноразовых задач, например студенческий диплом или какая-то отработка алгоритмов - можно поработать и на D и на чем-нибудь еще. Все зависит от требований к разрабатываемому программному продукту.

Цитата ("dervinar"):

Парни, которые "страдают такой херней", как написание серверных демонов постоянно пропадают и не оставляют своего адреса - действительно, зачем, вдруг благодарные клиенты еще клиентов приведут.. Ужас просто.
И, соответственно, есть талантливые Php - программисты, которые может быть и знают что такое переменные окружения и как к ним обращаться, но вот откуда эти таинственные переменные окружения берутся и как они вычисляют, какой браузер использует пользователь, даже не догадываются... И вот эти талантливые Php программисты всегда оставляют свои адреса, телефона, номера паспортов и еще кровью расписываются. Потому как клиентов любят...

Я, к сожалению, не совсем понял Ваш сарказм, но застявлять программиста расписываться кровью иногда было бы очень не вредно. На самом деле, клиентов любят и пропадают примерно все одинаково: программисты выходят замуж/женятся, переезжают, находят более привлекательную работу и т.д. В этот момент перед заказчиком (или руководителем проекта) встает вопрос: где взять замену и сколько это будет стоить. Очевидно, что писателей серверных демонов на рынке гораздо меньше чем писателей на php+mysql, следовательно шансы найти подходящую кандидатуру среди последних гораздо выше и стоить это будет гораздо дешевле (чем меньше на рынке какого-то товара, тем дороже за него готовы заплатить). Это соображение и надо учитывать при выборе языка/СУБД/среды разработки во время проектирования системы.

Цитата ("dervinar"):

И еще более правильно, что такой сайт надо как можно быстрее переписать на Php и MySQL - вот только одна проблема, дорого. На одних серверах разоришься - то, что отлично держалось на 1 сервере придется на 3 более мощных разносить... Приходится поддерживать...

Именно и приходится и поддерживать и разносить на 3 и на 30 серверов то, что когда-то работало на одном. И приходится это делать потому, что переписать кучу кода php+MySQL на какой-либо C, D, E или на очередную "революционно-новую" технологию займет примерно столько же человеко-лет, сколько заняла разработка уже имеющейся системы - плюс неизбежный "период нестабильности". А сколько стоит один человеко-год одного программиста? Правильно, пара-тройка серверов обойдутся дешевле, а возни с ними - меньше. Вот и выходит, что для большинства задач дешевле делать проект на том, что хорошо отработано и отлажено, на том с чем хорошо умеют работать имеющиеся программисты и на том что хорошо поддерживается и будет поддерживаться в обозримом будущем. И если таковой технологией является php+mysql и разработчики способны обеспечить технические требования к системе, значит и надо писать на php+mysql и помнить при этом, что любое переписывание работающей системы стоит, как правило, примерно столько же, сколько стоила начальная разработка и на переписывания "с чистого листа" лучше не рассчитывать.

Приношу извинения автору топика за разведение спора... Но, насколько я уже понял, Вы уже сформировали свое мнение по теме, при этом затронув очень важную и серьезную проблему: на чем писать крупные web - проекты?

Цитата:

Очевидно, что писателей серверных демонов на рынке гораздо меньше чем писателей на php+mysql, следовательно шансы найти подходящую кандидатуру среди последних гораздо выше и стоить это будет гораздо дешевле (чем меньше на рынке какого-то товара, тем дороже за него готовы заплатить).

Возможно и очевидно, но не совсем верно. Попробую развенчать данный миф. Программист который пишет ТОЛЬКО на Php и не знает ни одного языка программирования сверх этого - это не программист. Верно и обратное, хороший программист напишет на чем угодно - возможно, потратив лишние 2-3 недели на обучение. Вот то, что php это самый распространенный язык среди школьников - это да. Он простой, удобный, не очень критичный к откровенным косякам. Потому то и получается что найти программиста на php на несколько порядков проще чем на Java... А вот найти программиста, который не запорет проект на более-менее популярных языках шансы примерно равны независимо от языка. В качестве примера, предлагаю рассмотреть профиль топовых програмистов данного проекта. Имена буду опускать, кто сильно хочет - смотрите сами посилання
1)Php, Java

2)Assembler, Visual Basic, Visual C++

3)Java/J2EE - 8 years, last used: 2009
Perl/PHP/MySQL - 10 years, last used: 2009
.NET - 6 years, last used: 2009
Oracle - 3 years, last used: 2009
MS SQL - 2 years, last used: 2004
DB2 - 2 years, last used: 2003
C/C++ - 6 years, last used: 2008

4)Delphi, С# и VBA, FoxPro и Clipper.

5)asp.net(C#,V,winforms,SQL,PHP,perl,python,C++,java,delphi - это, насколько я понял, список языков которые данному человеку нужны.... Но не суть.

6)Delphi, C++, asm; WinAPI,COM, PHP, JavaScript

7)PHP, MySQL, JS, AJAX, HTML, CSS

8)php, mysql.

9)- html/xhtml, css, javascript (json,ajax), xml, php, mysql и др.

10) C++ – 6 лет
PHP – 3 года
PostgreSQL – 4 года
MySQL – 4 года
FireBird – 3 года

11) - Python, FreePascal/Delphi, JS, Assembler, чтение некоторых др. языков
- XML, XSL, DHTML
- XML-RPC, SOAP, SMTP, IMAP, XMPP и т.д. (преимущественно на Python)
- Nevow/Twisted, Django, Trac, Zope/Plone, небольшой опыт в Webware (это все Python)
- Threads, Windows Services, Client/Server, Sockets, WinAPI, COM/DCOM (поверхностно)
- DirectX, OpenGL, SDL/PyGame (поверхностно)
- ADO, BDE, ODBC, MSSQL2k, PostgreSQL, MySQL, Firebird, SQLite (предпочтения отдаю PostgreSQL и SQLite) - у этого человека отдельно написано, что Php и Perl не предлагать.

12) PHP, C++.

Дальше продолжать копипастить лениво - кто хочет, может сам пройтись по каталогу фрилансеров. Но в целом тенденция такова: программистов, у которых есть приличные проекты, и при этом они знают ТОЛЬКО php+mysql - единицы из сотен. При чем чем серьезнее проекты тем меньше шансов нарваться на онли phpшника.

Касательно переписывания... А я где-то предлагал выкинуть все то, что уже написано и переписать с нуля? 1с так 1с - если он удовлетворяет на 100% потребностям автора топика - значит именно его лично я и советую поставить. А вот если разрабатывать с нуля, то разрабатывать лучше не на Php и не на MySQL. Поскольку "период нестабильности" переживать в любом случае... Вот и получится что "2-3 сервера" выкинуты впустую.

Цитата ("dervinar"):

Приношу извинения автору топика за разведение спора.

Да я даже не в обиде, наоборот...я тут тихо в сторонке слушаю. глядишь умнее стану-буду................

А насчёт 1С я даже и не очень-то к нему.. на нём кроме установки ещё и самому учиться и ещё всех кто у меня будет на нём сидеть учить.
Мне как-то интуитивно кажется, что на каком-то создаваемом решении будет легче научиться работать, чем на 1C..

Развели ромашку.. что лучше, что хуже.
Третий месяц пишу систему управления компанией для заказчика(он у меня продвинутый, не хочет даже смотреть в сторону готовых систем).
Так как сам успел с предыдущим исполнителем хлебнуть горя - успел поверхностно изучить PHP и хотел только чтоб на нём всё работало. Ну пыхпых, ну мускул... Где наша не пропадала.

Итог: 50 офисов, 200 персонал, ежедневно от каждого офиса 30-50 записей в базу, ежемесячный экспорт детализации счётов от МТС(~27-40 000 записей единоразово ) с просмотром историй кто куда звонил..
и всё работает ОТЛИЧНО!

Да, согласен - рано делать выводы с базой за три месяца. Но я вижу узкие места, я знаю, что в первую очередь может тормознуть и как это поправить. Зато работа по разработке системы была проведена быстро и с огромным функионалом(за основу был взят streber). Надо будет - подкрутим запросы, воткнём мемкэш, релизуем пошаговую подгрузку где надо, делов то.

Главное уметь подстраиваться под ситуацию и под конкретный заказ. И надо УМЕТЬ писать с разными требованиями. К цене это, кстати, тоже относится.

А, и ещё - за время разработки я обучил своего заказчика PHP ещё глубже(по его инициативе) теперь по мелким доработкам он просто звонит и я ему ПО ТЕЛЕФОНУ объясняю что где подправить и что за что отвечает. Ну не прелесть ли

Цитата ("dervinar"):

Программист который пишет ТОЛЬКО на Php и не знает ни одного языка программирования сверх этого - это не программист. Верно и обратное, хороший программист напишет на чем угодно - возможно, потратив лишние 2-3 недели на обучение. Вот то, что php это самый распространенный язык среди школьников - это да. Он простой, удобный, не очень критичный к откровенным косякам.

Какие не продумманые и смелые заявления! Здесь не пахнет опытом. Создается впечатление, что товарищ dervinar является сотрудником проекта weblancer.net и посещает данный проект для приумножения дискуссий на тему - что такое хорошо, а что такое плохо. Так же я, почитав посты упомянутого товарища обратил внимание на признаки легкой демагогии и подмены понятий. Может человек здесь нашел место, где можно высказаться, почувствовать значимость..
Ну давайте, дерзайте. Вот только время других уважайте - тех кто ищет ответ и всех участников. Один раз высказались, и в сторону.. не надо всем отвечать от имени гуру..
И не обижайтесь, Вы похоже просто молоды..


РЕСПЕКТ alexander_vip. Чувствуется опыт и глубокие познания.

Цитата ("etrade"):

Какие не продумманые и смелые заявления!

Он совершенно прав.
Если программист знает только PHP и не знает больше ничего, значит это не программист, а обезьяна, которую выдрессировали использовать определенные конструкции языка или фреймворка.
Впрочем, такие тоже нужны, они обходятся дешевле.

Цитата ("alibek"):

Если программист знает только PHP и не знает больше ничего, значит это не программист, а обезьяна, которую выдрессировали использовать определенные конструкции языка или фреймворка.

То есть, если программист (волею судеб, так уж получилось) в течении нескольких лет работает над крупнымпроектом или, например, руководит разработкой проекта, ни на что не отвлекается, становится настоящим профессионалом в своей области, но навыки работы с другими языками постепенно теряет, а сами языки меняются, то такой программист уже становится, как Вы выразились, обезьяной? Профессионального программиста который знает один язык и знает его, действительно, хорошо на работу принимать нельзя? По Вашему получается, что крупные проекты надо разрабатывать силами вчерашних (или завтрашних) студентов, одинаково плохо знающих 5-10-15 языков?

Цитата ("alexander_vip"):

А, и ещё - за время разработки я обучил своего заказчика PHP ещё глубже(по его инициативе) теперь по мелким доработкам он просто звонит и я ему ПО ТЕЛЕФОНУ объясняю что где подправить и что за что отвечает. Ну не прелесть ли

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

Цитата ("Illarion_SA"):

что у пары тысяч записей в базе какое-либо второстепенное поле заполнено нулями - пустячок

мм.. были бы эти немного другие поля и в немного другой сфере бизнеса, то увезли бы Вас в лес...