Поставлен начальством отслеживать процесс создания сайта, до того ваял себе только пару домашних страничек на ajax... Выбор работников отдельный разговор, но есть совершенно не понятный мне вопрос по базам данных поскольку организационные вопросы на моих плечах а я даже тех задание затрудняюсь выдать. Суть: Есть много картинок, каждая имеет свои характеристики, некоторые из которых могут принимать более одного значения, к примеру страница публикации картинки, или стиль, ну или мало и что еще. Так вот можно создать много записей в базе данных где физически одинаковые картинки будут фигурировать столько раз сколько, дублируются их свойства, разве это правильно? Как потом вынуть из базы количество уникальных картинок? Плюс выходит путаница со свойствами... name page style 1img index1 classic 1img index2 modern 1img index2 classic если заводить отдельную таблицу style к примеру, то поиск в базе как я понял происходит по строкам а строка будет выглядеть странно classic modern img1 img2 img3 img1 Если писать в свойствах через запятую, то потом придется проводить парсинг строки, и как найти все картинки style modern к примеру? Понимаю, что вокруг такое делается на право и на лево (ключевые слова на пример, произвольно добавляемые пользователем) НО как? Всю голову сломал объясните? Можно без кода
Сделай 2 таблицы одну с картинками другую с их свойствами Таблица Картинки: ID Картинка Таблица Свойства: ID ID_Картинки Свойство 1 Свойство 2 Свойство 3 .... Картинка в базу записывается как бинарный файл или как строка полного имени файла?
Три варианта. 1. Одна таблица. В таблице ID, imgName, description... Праймэри ID. 2. Как показал Phantik. Т.е. две таблицы принцеп такой же, привязка по ID. 3. Три таблицы. Есть таблица описаний. IDdescription, description. Вторая таблица картинок. IDimage, SRCimage. И в третьей уже компонуем наши данные. Т.е. слепливаем из двух предыдущих по IDdescription, IDimage... Такая система более сложная. Но если же данные повтораются то это лучший вариант. Плюс можно слепить неплохую админку под эти три таблички. Что ещё больше упрощает работу в будущем. Добавил: Плюс если же свойства добавятся\удалятся к этим картинкам.. То это легко поправить.. По SQL запросу. Можно даже ничего не удалять. Если же добавляется то нужно создать новую таблицу с новыми свойствами IDsome, some. Ну а в главной таблице (сборочной) уже добавить поле (IDsome) дописывать ID этого some. Система довольно гибкая. Надеюсь понятно идею изложил. ^_^
Спасибо, понял так, использование id, и использование большего количества более простых таблиц, а дальше по ситуации Хотя полной ясности все равно нет Тогда другой вопрос. Мне активно советуют cms как решение всех проблем, но вот фрагмент разговора по аське, по моему он так и завис Потенциальный работник:gallery.menalto.com вот сайт бесплатной галлерии посмотрите Я: Ок почитал. Тогда наглядный пример. Делаем флеш с голой куклой барби, которую нужно одеть одеждой из нашего магазина, предположим у нас ранее была сделана галерея этой одежды на какой то cms. Сможем ли мы это сделать опираясь на ключевые слова когдато присвоенные картинкам одежды в этой галерее? Ну к примеру все шапки "шапки", красные "красные" и т.д. На этот вопрос я не могу найти ответ, похоже можно но это будет равносильно написанию плагина к галлереи потребует изучения ее api, или я преувеличиваю? Он: узечение api конешно потребуется, а вот плагин не обязательно, можно просто модифицировать код cms. Что думаете (надеюсь это еще не флуд ))
Цель большой и сложный сайт с програмными интерфейсами для пользователей, магазином и пр. Достижение цели через год полтора, а сейчас в начале пути хочется не наделать ошибок )
Вот от этого "и пр." зависит очень многое. Магазины есть стандартные, галлереи есть стандартные, форумы есть стандартные, блоги есть стандартные. Много чего есть стандартного. Вопрос в том что определенный набор увязать вместе может быть весьма сложно, если нет четкого проекта и понимания конечной цели. И даже команда разработчиков, которая буде решит писать индивидуальное решение, через год может выдать нечто такое, что проще будет переписать заново, чем добавить еще одну новую фичу. Поэтому определитесь с конечной целью. Потратьте 1-2-3 недели на то чтобы просто понять что вы хотите получить. После этого можно приступать к выбору способов достижения цели. Важно знать, что поставив цель вы в течении года не сможете все переделать и даже многие казалось бы косметические улучшения должны быть и будут отвергнуты.
все зависит от предполагаемых размеров таблицы. если там предполагаются миллионы записей, а page и style будут сотни-тысячи, то им путь в отдельную таблицу. а если десятка два - то оставить в одной и не париться.
Чертовски хороший совет ) Вот только обсуждать надо по видимому с командой будущих разработчиков. Что ж ждите в ближайшее время меня в разделе фриланс )