схема таблицы товаров - PullRequest
Новая
       13

схема таблицы товаров

4 голосов
/ 04 июня 2009

Мне нужно создать типичное приложение crud для «статей», есть ли стандарт или что-то вроде лучшей практики, когда дело доходит до этого? Я знаю, что каждое приложение и ситуация меняются, но я имею в виду в целом.

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

Мое определение статьи как: 

CREATE TABLE `articles` (
  `id` int(11) NOT NULL auto_increment,
  `issue_id` int(11) default NULL,
  `status` text,
  `updated_at` date default NULL,
  `body` text,
  `title` varchar(255) default NULL,
  `author` varchar(255) default NULL,
  `created_at` date default NULL,
  PRIMARY KEY  (`id`)
)

Ответы [ 3 ]

2 голосов
/ 12 июня 2009

Dublin Core - это неофициальный стандартный набор атрибутов для документов и носителей. Атрибуты:

  • Название
  • Creator
  • Тема
  • Описание
  • Издатель
  • Автор
  • Дата
  • Тип
  • Формат
  • Идентификатор
  • Источник
  • Язык
  • связь
  • покрытие
  • Права

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

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

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

1 голос
/ 04 июня 2009

Таблица статей: 

CREATE TABLE `articles` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `keyname` varchar(96) NOT NULL,
  `title` varchar(96) NOT NULL,
  `content` text NOT NULL,
  `tags` varchar(128) NOT NULL,
  `author` varchar(128) NOT NULL,
  `date_created` datetime NOT NULL,
  `date_updated` datetime default NULL,
  PRIMARY KEY (`id`)
)

Изображения статей: 

CREATE TABLE `articles_images` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `article_id` int(10) unsigned NOT NULL,
  `url_thumb` varchar(512) NOT NULL,
  `url_big` varchar(512) NOT NULL,
  `date_created` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `article_id` (`article_id`)
)

url_thumb - эскиз изображения
url_big - большое изображение

И вы можете проверить базу данных WordPress Chema

0 голосов
/ 10 июня 2009

Если вы просто хотите отобразить изображения и загрузить их с помощью ftp, тег image image подойдет

Если вы хотите, чтобы веб-интерфейс загружал их, сохранение путей в БД очень удобно

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

Это позволяет вам использовать что-то столь же удобное, как скрепка (плагин) для загрузки и хранения

...