Электронный магазин

VL, это не волгоградский заказ, я давно уже забил на волгоградские заказы.
А чего там магазин то писать?
Стандартная авторизация на куких + система шифрования+сессии на ip с базой данных(уже написанная).
поднять SSL - дело сис. адимина, а не меня.
Каталог продукции (движок есть, однако у каждого заказчика свои пожелания и виденья, так что с ним повозиться еще придется)
Корзина. Детство. На ее написание (на БД, а не на кукях) уйдет времени - несколько часов (1 табличка с данными + сортировка по ней).
Интеграция с ситемой оплаты по кредиткам - если есть р/c, то это дело 1 часа + несколько дней бумажной волокиты в бугалтерии.
Ну и интеграция с бугалтерией. Здесь все зависит от заказчика.
Если с 1 с бугалтерией и толковым парнем в помошниках, который способен нормально ее настроить - быстро, если свою писать - до недели времени.

И не будет в Волгограде нормальный интрент-магазинов еще года 2. Они не востребеованны. народ только к кредиткам приобщаеться, а что бы воспользоваться webmoney или Yandex.деньги - это нереально для многих...

ЗЫ. Просто так писать ничего не собираюсь. Уже валяются 2 проекта дома. Осталось только запустить их. Даже дизайн готов. Один из них - поисковик по сайтам нашей области + каталог сайтов + новости города + чат (на голову удобнее нынешнего волгоградского) + много чего. Короче готовый портал. 2 - система контроля и обновления контента сайтов, с интерфейсом по оброзу и подобию Ворда (js). И не запущу - нету времени на это. А когда есть - не до них... А потому что это бысплатные проекты.
А надо еще платные сделать: виртуальные открытки, международную службу знакомств, баннерообменную систему, форум, ...

 

micron,. сслыки выслать но подобные мои работы?
VL, нет - это действительно просто.
Есть таблица продуктов
products(product_id,product_name) и таблица заказов
,назовем ее accounts(number,product_id,customer_id)
number-номер заказа,customer_id-покупатель
SQL запрос по одному покупателю ,который бы выводил
все продукты выбранные покупателем в данном заказе:
В данном случае я думаю, подойдет
"естественное 'соединение".
Это означает, что можно устанавливать отношения на основе ее структуры , а
не содержимого базы, (неестественное соединение).
SELECT number,product_name,customer_id FROM products, accounts WHERE
customer_id='$login'.

Есть иной путь: создать представление (оно и будет аналогом 3 таблицы в mysql).
И вообще то это связь многие - ко многим.

Вот кусок для обновления контента сайта (редактор новостей, урезанная версия)
http://plazma.ru/interactive/editor/
Надеюсь меня остапом больше называть не будут? Меня Сергеем зовут...

 

для некто.
про магазин.
это не магазин у Вас, это базар получается. я делаю вывод по тому, что из нескольких часов теоретических размышлений, пары табличек, и одного запроса - только такое и получится.
меня удивляет такой подход к проектированию ИС. сначала что-то сделаем, а потом начнем использовать. для того, чтобы говорить о том, что сделан магазин, надо бы сначала проанализировать требования/бизнес-процессы/прецеденты/потоки данных, а две таблички - это в самом конце должно получиться. например в магазине возможно отложить товар, оговорив сроки оплаты, а вслучае если нашелся второй клиент, который готов оплатить этот же самый товар раньше, а поставка второй партии успевает под оплату первого клиента, то второй забирает товар первого - несколько часов говорите + сортировка ;-)
про редактор контента.
(такой как Вы привели в примере).
чем Вас не устраивает SharePoint Portal Server?

 

да магазины я люблю писать! ))
вот оцените например полностью моя работа (дизайн и программирование) мускул и прочее
http://www.mp3store.ru

Ну вообще магазин ещё надо сделать БЕЗОПАСНЫМ!

 

Ого, господа модераторы для нас открыли новую тему!
Спасибо вам!
Гость, по поводу требований.
Это уже анализировалось не раз. То что я описал - основная и упрощанная схема, показываюшая общий принцип. И она анализировалась не одни час или день... Потому сейчас все быстро сделается - обдумывалоссь не раз + есть некторые заготовки.

Наличие - отсутствие заказа должно выводится и определятся в самом каталоге. А то получится, что человек захотел что-то купить, занес в корзину, а товара на складе нету.
К корзине это тоже должно быть привязанно, согласен, но я не вижу в этом трудности. В таблице с товарами есть ячейка с количеством товара на складе. При покупке, нужная часть отнимается. Вы хотите сказать, что это сложно сделать? Вряд ли...
Второй купил раньше - в строке товара изменились данные в ячейке, которая содержит общее количество этого товара на складе. Все. Второй опередил первого. Первый в пролете. Причем, на мой взгляд, можно и нужно сделать ему автоуведомление (запуск скрипта который это будет делать через крон, по расписанию) о том, что товар был перехвачен другим. Пр желании можно сделать релевантность, т.е сделать возможность в течении дня все купить первому человеку, а потом разрешить второму. Но это зависит от заказчика... И это уже не относится к корзине.

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

PIXELO, хе...
SSL+куки+проверка ip+система сессий+шифрование паролей в базе по динамическом ключу = приемлемой защите.
Защиту от перехвата данных кредиток дают огромное количество сервисов - систем для оплаты по кредиткам для подобных сайтов. Осталось только выбрать подходящий, да оплачивать ему около 5% от сумм оплат.

Добавление от [date]1051643423[/date]:
VL

См выше. (не один день обсуждений и начертания блок-схем + определенное количество заготовок.)

 

Зы, для виртуального магазина MySQL я бы не рекомендовал использовать.
Используйте более стабильные и надежные базы типа Oracle.

 

NEKTO
мускул = MySQL
А кто сказал что Oracle стабильнее и надёжнее ? : )

 

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

по-поводу легко и просто.
в случае одного требования, например, того, которое привел я труда не составляет все реализовать так как надо. но! представьте себе, что этих требований у заказчика 200. во-первых, их надо собрать - это требует времени и проанализировать: выявить основные требования, которые могут повлиять на функциональность продукта, выявить неосновные требования, которые можно будет доделывать потом, определить пересекающиеся или противоречивые требования, наметить пути разрешения конфликтов и т.д. и т.п. и затем составить спецификацию ИС. на это уйдет достаточное количество времени, точно говорю - не несколько часов. затем надо провести проектирование системы, в том числе и выбор технологии реализации. затем то, что Вы спроектировали надо реализовать (200 требований, по одному за день, 200 дней/20 рабочих дней = 10 месяцев). дальше пошло тестирование, опытная эксплуатация.
мне удивительно, что это я должен рассказывать человеку, который заявляет, что профессионально создает информационные системы.
по крайней мере, если бы ко мне пришли с таким предложением, я бы от сотрудничества с такими разработчиками, которые адекватно себе не представляют процесс разработки, просто-напросто отказался. вот так и получается, что многие ИС представляют собой всего-навсего поделки студентов, сравнимые с курсовыми или дипломными работами.

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

ПС. немного длинновато вышло, но в предпразничный день настроение лирическое.

ПСС. по поводу того, что Вами это анализировалось не раз и есть домашние заготовки. системы делятся на тиражируемые и заказные. в каждом случае существуют свои особенности, схожести и отличия и свои правила создания, заметьте не методологии, а правила (методолгию можно выбирать, а правила - нет). Вы себе четко представляете это различие? похоже, что нет.

 

PIXELO, VL, зайдите на http://SecurityLab.ru, почитайте сами.
Потом почитайте мануалы Oracla. Их я цитировать не собираюсь...

Гость, ваши слова не лишены смысла, согласен. Однако, ко всем вашим возражениям привидите мне эти 200 отличий в магазине Болеро и Азоне, н-р...
Общий движок у ник одинаков. Различие не в корзине, а в каталоге. А почитайте, что я написал выше про него...
Вы хотите сказать, что написание с нуля подобных скриптов - не нужное действие? Боюсь многие с вами не согласятся...
http://www.deforum.ru/forum/viewtopic.php?t=11981
А программисты там с весьма солидных агенств Москвы и Питера.

Вы себе противоречите...

Во многом я с Вами согласен, однако обычно требования заказчика носят стандартнй шаблонный характер.
Примеры:
1)Плазма: Хотим форум как http://forum.volgograd.ru Попытки сказать им, что такой есть и он уже написан, не увенчались успехом. Они хотят что бы им написали такой-же.
2)http://russiandating.ru (дизайн еще в доработке). Хотим как http://bride.ru
Все изменения и непохожести с bride.ru - это уже моя инциатива, согласованная с заказчиком.
...

ну не совсем домашние....

Жаль, если я произвел такое впечатление. В любом случае не мне судить. Однако свою работу я знаю и заказы успешно здаю и они успешно работают.

ЗЫ. Я читал эту статью, вы намерное имелли ввиду то, что ниписанно там:
http://deforum.ru/stat/magaz.htm
Более того, я с ней согласен. Однако это не меняет сказанного мною выше.

И на последок.

Уверяю вас, что многие программисты в крупных русских и заграничных агенствах имеют возраст от 20 до 25 лет. И они делают далеко не черновую работу.
До меня на моей работе был умный программист который делал один сайт. Он работал, был составлен именно так, как вы объяснили - по требованию заказчика. Однако он был написан настолько криво и не массшабируемо, что для того чтобы добавить в него несколько новых сервисов, мне пришлось писать его по своему с нуля. Теперь добавление нового сервиса занимает короткое время, т.к. сайт, по сути дела - стал набором модулей.

Я думаю, что не стои продолжать наши дебаты, в попытках доказать, кто же из нас все же умнее...
Вы пока не представили мне реальных доказательств моей не правоты.

 

для Некто.
по поводу 200 отличий и шаблонных требований заказчика.
найдите все-таки сами правильные определение для заказной и тиражируемой систем.

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

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

ПС. почему, когда ведутся такие беседы, то довольно частенько они воспринимаются как мерянье сами знаете чем?
я не пытаюсь доказать Вам, что я умнее или Вы глупее. я пытаюсь Вам, сказать, что у Вас в голове некоторая неразбериха по поводу ИС, может быть это связано с отсутсвием специализированного образования или отсутствием реального общения с разработчиками. поверьте, многие мои замечания к Вашим высказываниям вызваны только тем, что Вы действительно не совсем так представляете себе процесс разработки и иногда путаетесь в терминах. но от этого надо же избавляться!

ПСС. эту статью я не читал. а теперь смотрите, вы с ней согласны, но это не меняет сказанное выше. значит какие-то отличия есть! Вы просто не можете их выразить в терминах.
кстати в этой статье я тоже не увидел строго подхода, так что...

 

Это был ведущий программист нашего солидного городского провайдера.

Однако Вы меня поняли. Я не старался сохранять чистоту русского языка и правильность определений.

На самом деле я благодарен Вам за эту беседу. Ваше мнение интересно и важно для меня.
По поводу отсутсвия образования - согласен, у нас в городе нету достаточно качественного образования по web-программированию. А сертификацию я проходил только по дизайну. Я самоучка
Общение было и будет, я работаю в этой сфере на нормальном уровне (не удаленно, а в реально существующих конторах) уже не один год и не два... И покажите мне хорошего программиста и не самоучку. Любое обучение не способно научить всем тонкостям - их надо осваивать самостоятельно.

Я думаю, что мы действительно не правильно поняли друг - друга.
Там проводится отличия между системой заказов и виртуальном магазином. Однако это не менят того, что я написал выше. Смысл написанного был таков, что используя готовые модули, можно на их основе сделать полноценный виртуальный магазин, а не писать его с нуля. В этом мы и не поняли друг друга.
Кстати, с кем я имею честь бесодовать?

 

Первый вопрос который я задаю заказчику - пожделания относительно языка программирования, на ктором будет писаться система и сформированое ТЗ.
ТЗ долно представлять список пунктов. При здаче заказа заказчик расписывается напротив каждого из них - что все сделанно так, как он хотел.
Т.е. я делаю так, как вы говорите надо работать. Просто в работе я постояно использую готовые программные решения, при условии, конечно что языки программирования - Perl и ASP. На других языках просто у меня нету токого количества заготовок и модулей. Именно их использую,а не подгоняю под заказ.

 

Использоваь наработанное (своё) в сових будущих целях как шаблоны или скелет удобное и более того полезно. Например тем что время экономит.

И всё таки большая часть систем создаёться с помощью MySQL. Именно эту базу признали веб-разработчики, значит она лучше и это нельзя оспорить. Почему же все её пользуються.

 

для Пиксело.
MySQL - либо бесплатен, либо стоит очень немного, отсюда и его популярность. опять же не задачу под продукт надо подгонять, а продукт под задачу.
дальнейшее обсуждение может свестись к обсуждению серверов СУБД. Вы к этому готовы, у Вас есть необходимые знания для этого?

для Некто.
меня зовут Александр Ткаченко.

насчет документа, который необходим для разработки информационной системы.
то, что Вы называете ТЗ (список пунктов), на самом деле ТЗ не является, достаточно посмотреть на ГОСТ, чтобы убедиться в этом.
говоря о том, что ТЗ содержит все необходимое перед началом работы, Вы загоняете себя и заказчика в очень жесткие рамки "водопадного" процесса. конечно, если Вы разрабатываете кардиостимулятор или космическую станцию, то это скорее всего будет правильно (я их никогда не разрабатывал, пэтому не могу судить об этом).
не лучше ли отказаться от документа ТЗ, благо существующие средства разработки при правильной архитектуре приложения позволяют практически "на лету" перекраивать приложения, а просмотрев несколько современных методологий остановиться на какой-либо и выбрать для себя оптимальную, хотя бы в части формулировки требований, чтобы оставить свободу и себе и заказчику. но как известно из закона сохранения, если в одном месте прибыло, то в другом убыло, поэтому в этом случае надо более тщательно прорабатывать контрактную сторону, содержащую сведения о протокольной цене договора, принципах оценки сроков и доработок. мне кажется этот варинт наиболее оптимален, ведь не секрет, что заказчик поворачмвает если не вспять, то в сторону почти на самой середине процесса разработки ПО и, в случае жесткого регламентирующего документа, головная боль достается обеим сторонам. поэтому я и предпочитаю этот документ называть спецификацией, а уж что там будет, зависит от выбранной методологии.

насчет хороших программистов.
как я их Вам могу показать, разве что фотокарточку принести? ;-)

ПС. я не всегда пишу так много. просто на сегодня оставлено очень мало дел.

 

Гость, приятно познакомится. Я Тарасенко Сергей.
Именно, есть подобные заказчики, которые в середине работы говорят "я передумал, зделайте не это, а то, да не так, а эдак".
В итоге выполнение заказа растягивается на неопределенный срок. Имеено поэтому я стал использовать подобный неформальный документ, который я назвал ТЗ или его приложением, если вам так будет угодно.
PIXELO, Гость прав. MySQL распостраняется бесплатно.
И она не имеет технической поддержки. Т.е. она распостраняется как есть. С тем же Ораклом дело обстоит несколько иначе.
Дальше, вы сталкивались хоть раз с администрированием БД MySQL?
Так вот, сделать так, что бы она работала стабильно и не "падала" - весьма сложно.
С Орасле дело обстоит несколько иначе. Если она встала нормально (что в моей практике происходит далеко не всегда, ставил под Сорярис и Линукс), то надо суметь ее "уложить". Мне это удавалось только переполнением кеша, приусловии, что патчи на нее не были установлены.
Кроме того у не более хороший внутренний SQL отладчик + огромное количество функций, который только начинают вводить в MySQL 4.+. И вводить будут скорее всего не один год.
Она до сих пор поддерживает только 2/3 стандарта SQL99.
Еще пример:
После тестирования на скорость отработки Oracle и MySQL.
Быс сформтрован подобный запрос (наиболее простой из всех, котрыми мы тестировали):
select count(*) from table where stolbec like '%word%'.
В обоих базах были зозданны предварительно полностью идентичныее таблицы с столбцом stolbec (VARCHAR 126) и количеством строк в 100 000. были созданны индексы таблиц.
Так вот подобный запрос был выполнен в 2,709 раза быстрее на БД Oracle. Операционка - Сорярис.
Делайте выводы господа...
Кстати стоимость БД Oracle составляет около 5000$ + немалая зарплата сис. админу, который обладает соотвествующими знаниями для ее администрирования (самые скромные у нас по городу они просят от 400$).
Если покупать хостинг с этой Бд, то его стоимость возрастает на 80-100$ в месяц на российских хостингах.
Вот по этому и выбирают эту БД. Кстати, почтовый сервер newmail.ru и mail.ru по моему используют именно Oracle (как минимум год назад ее использовали).
ЗЫ. Во флейм-то развели...

 

Нет с администрирование и настройками БД я не занимаюсь. Мне это и не нужно. Мы же вроде спроим о достоинствах.
А для этого хватает пользования. Я пользуюсь MySQL постоянно и пока что доволен!

 

VL, я же сказал, что готовых и полностью работающих магазинов у меня нету, есть некие подобные вещи, так как сами магазины мне не заказывали.
Есть куча заготовок, нарисовонных блок схем. Отсканировать и выложить? Я вроде не веду бесплатные курсы про программированию...
Или вы просто хотите проверить мои знания в данной области, типа "сказал, а теперь докажи!"?
Я могу лишь перечислить мой скромных послужной список как программера:
1)Университет-Телепорт. Этой конторе я посвятил 2 года.
Сделал: нынешний сайт, систему статистики для диалапщиков, систему создания (я+Токмаков) и пополнения счета по ним (Я). (кстати, я там уже приличное время не работаю. так что вя куча дырок на сайте - дело не моих рук, а нынешних горе-программистов.) Так же были проведенны работы по переписанию ситемы администрирования диалапщиков, биллинговой системы (все на БД Oracle). Были сделанны системы контоля и статистики диллеров, с формирующимися рейтингами + кача мелочевки.
2)http://www.interdes.ru/ для них сделанны 2 сайта.
Один http://www.crystalgiftsworld.com/ (такие вещи я называю халтуркой, однако это некое подбие магазина, хотя все же не совсем.)
3)Удаленная работа. Около 7 работ. Основные заказчики: Продюссерский дом Д. Маликова (в их числе мой нынешний заказчик - группа Плазма. кстати вот для них сейчас ведуться переговоры по созданию их официального виртуального музыкального магазина), http://russiandating.ru (+ куча проектов для них же). Кстати, там тоже сформированны различные группы прав пользователей, интергрированные с системой оплаты и еще куча всего. Для VIP категории сформированна некое подобие карзины.
4)Работа для себя. Что я сделал - см выше.

Еще вопросы? Или вам показать мои работы, как дизайнера?
PIXELO, вы хоть раз делали систему авторизации, рассчитанную на 100 000 и выше пользователей?
Мне будет инетерсно, как вы сделаете ее, не нагружая сильно сервер, слделаете по уму, не передавая пароль в открытом виде в http заголовке, а ключи и без хранимых процедур? А я делал... И отказался от этой БД.
Открою вам секрет, я тоже, обычно использую MySQL, но лишь по причине того, что мне не нужна мощь Оракла, да и дороговато его использование.

 

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

 

неа, не делал. расскажи подробнее

 

мда ... очень интересно!
только давайте не ругайтесь, а то я тоже вступлю в спор!

Очень интересно посмотреть! ... ...

и про это тоже расскажите!

 

VL, объясняю алгоритм.
В базе хранятся данные пользователей, включая их пароль.
Пароль хранится в закриптованном виде по динамически генерируемому ключу (требование заказчика).
После успешной авторизации, пользователю присваеватся ключ (паролне передаеься в откртом виде).
Однако в связи с тем, что необходимо проверять на совпадение ключ пользователя при каждом обрашении к серверу (и если учесть что подобных запросов много, около 5-100 в секунду), то оптимальный выход из ситуации - это хранимые процедуры. Не создавать же индекс базы, когда в день регистрируется около 1000 человек...

 

Напомните мне, где я такое писал...

См. приват.

 

Nekto а вот у меня вопрос, не по теме правда.
Как мне сделать чтобы таблица в мускуле обнулялась раз в сутки ? :