Создание приложения для классификации / описания продуктов - перегружено где-то между планированием и выполнением

Question

Привет!

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

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

На картинке написано тысяча слов, поэтому вот ссылка на сделанную мной диаграмму, показывающую, чего я пытаюсь достичь: http://i.imgur.com/gUuxB.png

В настоящее время я пытаюсь добиться этого с помощью CakePHP / MySQL. Я не слишком инвестировал в них, и я открыт для предложений по альтернативам. Возможно, CMS уже имеет эту функциональность? Какая-то штуковина с открытым исходным кодом? Python / Django?

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

Любой совет о том, как решить эту огромную задачу, был бы полезен. Я провел почти 4 недели в фазе планирования и больше не могу видеть лес за деревьями. Моя голова вот-вот взорвется.

Спасибо!

Answer 1

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

Какой интерфейс они ожидают увидеть? Интерфейс, который вы разрабатываете, должен отражать наиболее распространенные варианты использования!

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

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

Answer 2

Приятный рисунок:)

Проводили ли вы какие-либо эксперименты с фактической структурой таблицы? Это не выглядит так трудно. Вот попытка сделать все как можно проще.

==products==
id[int]
number[varchar]: unique, ie. #50-334 
category_id[int]: has-one relation to category.id

==categories==
// What you call branches in your drawing.
id[int]
parent_id[int]: tree structure
title[varchar]
description[text]
image[varchar]

==attributes==
id[int]
attribute_type_id[int]: has-one relation to attribute_types.id
is_universal[bool]: is this attribute used for _all_ products?
name[varchar]
value[varchar]

==attribute_types==
id[int]
codetag[varchar]: name to identify the attribute type from the code. Each type haves different validation. Some types will maybe be validated using data from helper tables.
title[varchar]
description[text]

==products_has_attributes==
// "Join table" with many-to-many relationship between products and attributes.
id[int]: Optional
product_id[int]: has-one relation to products.id
attribute_id[int]: has-one relation to category.id

==categories_has_attributes==
// "Join table" with many-to-many relationship between categories and attributes.
id[int]: Optional
category_id[int]: has-one relation to products.id
attribute_id[int]: has-one relation to category.id

Первый черновик. Прочитайте это как таковое.

Answer 3

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

Что касается EAV, посмотрите http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ Если вам все еще действительно нужно это сделать, рассмотрите hstore PostgreSQL. (Google, у меня нет представителя, чтобы опубликовать ссылку.)

Answer 4

Такого рода вещи в Django очень просты (если я действительно понимаю, о чем вы спрашиваете). A models.py примерно так:

from django.db import models

class Item(models.Model):
   price = models.DecimalField(max_digits=9, decimal_places=2)
   material = models.CharField(max_length=100)

class Sprocket(Item):
   length = models.DecimalField(max_digits=9, decimal_places=6)
   shape = models.CharField(max_length=100) # straight/curved

class SprocketProduct(Sprocket):
   radius = models.FloatField()
   maxload = models.FloatField()
   weight = models.FloatField()
   color = models.CharField(max_length=100)

более или менее сделает свое дело. Здесь SprocketProduct наследуется от Sprocket, который наследуется от Item.

Кроме того, запрос Item.objects.all () даст вам все элементы, Sprocket.objects.all () даст вам только звездочки - вы поймете идею.

Answer 5

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

Cake также имеет поведение Tree, поэтому оно может служить основой для вашей схемы. И он настоятельно рекомендует разумные значения по умолчанию, поэтому он заставит вас думать о ваших данных очень структурированным образом.

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

Короче говоря, это хороший способ навязать структуру вашим данным (и коду). Это быстро для развития. И у вас нет требований к производительности.

Answer 6

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

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

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

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

Answer 7

Кто будет использовать приложение? Сколько человек одновременно? Какие-либо конкретные причины для выбора CakePHP?

Из того, что я слышал, Rails и CakePHP вовлечены в "магию"; это становится проблемой, когда все вдруг не работает, и вы не знаете, почему. Если приложение предназначено только для сотрудников компании, и ваша конечная цель состоит в том, чтобы классифицировать эти инструменты, самый простой способ заключается в использовании Python с SQLite.

Но самое простое не обязательно означает лучшее:

Плюсы: - Использование Python означает, что когда вам нужно будет внести изменения в ваш код, это будет относительно безболезненно. - Использование SQLite равняется простоте использования; настройка не требуется вообще. Если вы используете Python 2.5 или выше, SQLite встроен, и его очень легко использовать. - SQLite просто взаимодействует с одним файлом .db, поэтому, когда вам нужно переместить / изменить / экспортировать данные из вашей базы данных, не будет никаких хлопот.

Минусы: SQLite не обеспечивает строгого соблюдения типов. Это означает, что даже если вы установите атрибут как «целое число», кто-то может прийти и поместить туда текст, и SQLite с радостью примет его. В зависимости от того, сколько данных могут делать другие люди, это может стать проблемой, поскольку у вас могут быть противоречивые данные. - SQLite предназначен только для нескольких клиентов одновременно. Если многие люди будут использовать вашу базу данных, вам придется использовать MySQL вместо этого. - SQLite не будет работать с терабайтами данных; это может или не может быть ограничением для вас.

Answer 8

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

Тот, кого вы уже поняли, я бы порекомендовал пройти по маршруту Python / Django или посчитать Rails быстрым способом добраться туда, куда вы хотите.

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

Ben