Остальным это и не надо. Инфляция все простит, а если не простит, то есть девальвация, а если и она не покатит, то есть свежий закон о банкротстве. Все что угодно, лишь бы не заниматься фин.образованием:)
Недавно читали http://www.yaplakal.com/forum23/topic1254419.html , в тему.
Топик сильно похож на фарс, но раз уж на то пошло, то
и соответственно
CREATE TABLE `zena_status` ( `id` int(11) NOT NULL AUTO_INCREMENT, `ord_zena` tinyint(1) DEFAULT NULL, `kro_zena` tinyint(1) DEFAULT NULL, `pro_zena` tinyint(1) DEFAULT NULL, `text` varchar(255) DEFAULT NULL, UNIQUE KEY `un` (`ord_zena`,`kro_zena`,`pro_zena`), KEY `id` (`id`) USING BTREE) ENGINE=MyISAM AUTO_INCREMENT=13 DEFAULT CHARSET=utf8;INSERT INTO `zena_status` VALUES ('1', '0', '0', '0', null);INSERT INTO `zena_status` VALUES ('2', '1', '0', '0', 'ord_zena');INSERT INTO `zena_status` VALUES ('3', '0', '1', '0', 'kro_zena');INSERT INTO `zena_status` VALUES ('4', '0', '0', '1', 'pro_zena');INSERT INTO `zena_status` VALUES ('5', '1', '1', '0', 'ord_zena,kro_zena');INSERT INTO `zena_status` VALUES ('6', '0', '1', '1', 'kro_zena,pro_zena');INSERT INTO `zena_status` VALUES ('7', '1', '0', '1', 'ord_zena,pro_zena');INSERT INTO `zena_status` VALUES ('8', '1', '1', '1', 'ord_zena,kro_zena,pro_zena');
Хотели бы мы посмотреть на эту же таблицу, когда у ТС будет 16 разных цен. Это ж ппц. Да еще апдейтить это постоянно.
Нене. Так нельзя делать.
Если уж менять структуру, то разумнее сделать таблицу (item_id, price_type, price_value)
где в item_id положить ИД товара, в price_type тип цены (ord, kro, pro) и в price_value непосредственно значение цены. Потом по ней делать выборки уже с группировками и фильтрами.
Но особого смысла в этом при небольшой базе нет.
Это просто следствие проекции гуманитарного заказчика на технического программиста:)
Есть вот такая цитатка
Ошибка очень многих заказчиков в том, что они на словах просят одного, ожидают другого, а третье подразумевают.
Не фиг от программиста, существа технического и точного, ожидать что он будет выполнять то, чего заказчик "ожидает" или "подразумевает".
ТС "ожидал" что программисты будут "не пропадать", но разве он хоть с кем-то оговорил, что они должны быть всегда у него на подхвате и доступны? Нет. Не сказал - не получил.
Заказчик заказал скрипт и в случае его поломки начинает кричать что его обманули. Потому что он "ожидал" и "подразумевал", что скрипт будет работать вечно и не ломаясь. Но в чем проблема на самом деле? В том, что заказчик не сказал что ему нужна гарантия и не оговорил ее условий. Не сказал - не получил.
Вот еще заказчик, которому сказали что скрипт будет готов где-то через недельку, скрипт ему делают 10 дней и начинается драма. Кидала, негодяй, я потерял миллионы. А где причина драмы на самом деле? Причина опять же в том, что заказчик не сказал что ему критичны сроки. Не сказал - не получил.
Другой заказчик, договорился что работу сделают ему через 10 дней. Каждый день ломится по всем контактам и требует держать в курсе. На 3 день не видя прогресса начинает кричать и тут явно какое-то кидалово. Оказывается он "ожидал" и это "подразумевается", что программист каждый день будет докладывать о работе и показывать прогресс. А в чем проблема-то на самом деле? В том что заказчик не сказал, что ему это нужно. Не сказал - не получил.
Отдельная тема это четкое ТЗ. "мне нужен типичный магазин". Окей. Ставишь ему битрикс. Что дальше? "А вот я на амазоне видел такую кнопку, почему ее тут нет?". Да потому нет, что типичный магазин понятие относительное (битрикс типичный? типичный - значит задача выполнена, а угадывать что заказчик под типичным подразумевал это не задача программиста, он не телепат) - как задание поставил, так результат и получил. Не сказал про кнопку - не получил кнопку.
Программисты перестанут пропадать, срывать сроки и так далее, когда заказчики при заказе будут открывать **** рот и ГОВОРИТЬ о том, что им это нужно и оговаривать разрешение ситуации, в случае если они этого не получат. Не оговорили, не договорились - значит всё, в сад, в гуманитарный вуз или женский клуб на крайний случай. Телепаты угадывающие "ожидания" и "подразумевания" водятся только там.
Фуф, кажется отпустило:) Adviscash, не воспринимайте лично на свой счет, просто Ваша цитата к месту пришлась, что бы на нее ответить.
Есть же типичные договоренности и по поводу пропадания после сдачи проекта и по поводу соблюдения сроков
а) "Антипропадайка". Заказчику гарантируется, что (допустим) в течении 6 месяцев после сдачи работы, если у него возникает какая-то проблема, исполнитель приступает к ее решению в течении суток и решает ее тратя не меньше 4 часов в сутки. Заказчику это стоит доп.денег, в свою очередь если прогер не реагирует на проблему, ему это стоит штрафов. И все довольны. Почему? Заказчик сказал что ему нужно.
б) "СрывСроков". Каждая задержка оценивается в определённую сумму. Сумма оценивается заказчиком самостоятельно, исходя из критичности для него сроков. Разумеется, заказчику это стоит доп.денег, но и от срыва сроков он не пострадает финансово, т.к. получит компенсацию.
Нужно что бы "не пропадал" и "не срывал" - оговорите это. Всё.
postavkin,
1) А куда еще проще-то? Чем Вам сложен уже подсказанный вариант?
2) Тут условие можно как-то так задать (if(kro_zena>0,1,0)+if(ord_zena>0,1,0)+if(pro_zena>0,1,0))>1
Тут не вполне согласимся.
Если база только mysql с myisam, то этот набор файлов вполне полноценный бакап. Иногда даже более интересный, т.к. если база с индексами и гига под 4 - можно замучаться ее восстанавливать из sql файла. Мы лично только в исходниках между своими серверами и таскаем, если там myisam.
Разница тут не между бинарными файлами и файлами импорта, а между sql файлом и zip архивом с этим же sql файлом. Потому что да - нужен конечно доп. движение для восстановления, но восстановление не будет железозависимым и не потребует каких-то сверхусилий.
В чем мы согласны, так это в том, что при продаже конечно надо отдавать sql-ку, но не по техническим причинам (неполноценность бакапа, не бакап), а по этическим (предпродажная подготовка, отношение к клиенту). Это без порно.
SeVlad, вопрос на засыпку. Согласно Вашему определению mysqlhotcopy бакап не делает, так получается?
Рубль вырос на 0.7%, нефть поднялась на 2.4%. Вывод = рубль упал на 1.7%.
Посылать в асв нотариально удостоверенное заявление на выплату.
Или же заглянуть попозже, благо времени обычно достаточно
Нет такого понятия как компенсация "по умолчанию" за срыв сроков если Вы юр.лицо, это надо прописывать. Для физ.лиц есть зозпп, но в отношении юр.лиц (заказчиков) он не работает.
Если штрафы не прописаны, но сроки указаны, то срыв сроков следует рассматривать как одностороннее нарушение договора стороной сорвавшей сроки. Тут опять же зависит от того, что это за сторона, но если это юр.лицо, то Вы можете поднимать вопрос о своих убытках (недополученной прибыли) в результате срыва сроков. Доказывать оные будет тяжело, но если докажете - это и будет компенсацией, на которую можно рассчитывать. В разумных пределах впрочем, так, например, при договоре на 100к, вряд ли кто-то будет компенсацию выплачивать 1млн.
