mirrustam

таких много

Я использую КМС Joomla, в ней есть неплохой встроенный редактор в виде модуля . Думаю, отдельно именно его тоже можно найти. Можно и другие.

вот так он называется WYSIWYG - редактор tinyMCE

храните целыми в копейках

Спасибо, я так понимаю вы описали мой "Вариант 2" своими словами, при этом добавили в таблицы Org и section(part) таблицы meta и content. Таблица контент необходима затем, чтобы пользователь мог добавлять не только текст на страницу но и заголовки, ссылки, картинки. В вашем случае ему придется писать html теги, чтобы добавить ссылку например или самостоятельно добавлять картинку и указывать src.

Я сам склоняюсь к варианту №2, но все-таки думал, что есть третье более оптимально решения без повторения одних и тех же полей в разных таблицах

на ваш второй вариант , по моему совсем не похоже

немножко непонятно зачем вам хранить отдельно ссылки.

на счёт, того, что надо писать теги - нет не надо - просто к текстовому полю прикрепите html редактор, он вам сам всё переведёт в хтмл

это решение оптимальнее, удобнее и правильнее. поля с одним и тем же названием относятся к разным объектам, и прикреплять их к своим объектам необходимо для :

1 .облегчения дальнейшей разработки.

2. достижения оптимальных скоростей работы(меньше соединений при формировании запросов)

да и по логике видно, что надо вам именно так

1. таблицы мета и контент – можно объединить в одну.

2. зачем вообще нужна таблица «контент»?

Если под «статьями» имеется ввиду описания разделов

Вот так будет правильно:

—section--

Id

Name

Description

meta_desc

meta_keys

meta_titles

--Org --

id

name

description

meta_desc

meta_keys

meta_titles

--section org --

id_section

id_org

description

meta_desc

meta_keys

meta_titles

поля description и мета… есть в каждой таблице . т.е есть описание для разделов, общее описание каждой организаии , а так же описание каждой функции для каждой организации.

Not null

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

Если так, то добавляется ещё одна таблица:

--content—

id

id_section

id_org (это поле может быть пустым)

text

meta_desc

meta_keys

meta_titles

Мат моделирование, конечно лучше. Но только если очень хорошо знаешь/любишь математику. Программирование изучишь и там и там. Да и лишних/неинтересных предметов хватает в обоих случаях. Если отбросишь не желание изучать лишнее , то сам быстрее поймёшь куда хочешь

D.S.Denton, спасибо тебе огромное, что не поленился так подробно расписать идею оформления БД и даже с примерами. В ближайшие дни, как появиться свободное время, попробую подумать о "правильной" организации своей БД по твоему примеру и по твоим комментариям. Идея сама мне понятна, но смогу ли всё так "грамотно" реализовать... Тут уже вопрос интересный. Помоему всё не так сложно, но... Пока не попробуешь, не стоит зарекаться.

В любом случае спасибо за ответ! Если честно, не ожидал, что так подробно кто-то ответит.

Давайте я тоже попробую .

1. Сначала подумайте и определите какие вопросы (запросы) будут к базе данных и сделайте список. Например так:

Найди все книги этого автора

Найди все книги именно этого автора

И т.д.

Тогда вам самому будет понятнее как всё построить

На счёт в одну таблицу аудиокниги и просто книги – лучше сделать в одной таблице и разделять их по полю «тип книги»- так как и то то книги.

Кроме того, есть ещё одни вариант: можно использовать поле формат как признак наличия форматов например:

1- есть книга в обычном формате

2- есть книга в обоих форматах

3- есть книга только в аудиоформате

т.е. вне зависимости от того есть у вас аудиокнига, просто книга или оба варианта всё равно будет только одна строка на одну книгу.

Советую поискать в Интернете и понять – что такое «нормальные формы таблиц» -их всего пять – но если вы все свои данные приведёте хотя бы к третьей, то база сама по себе будет правильная.

ясно, мне такое не подходит... ключи я почти никогда не прописую, при вставке я всегда использую автоинкремент...(

Но всеравно спасибо, было интересно узнать о чем то новом.

но ведь if вы собирались делать по какому то условию

если нет ключа , тогда только выборкой select - и если не не нашли тогда вставить, нашли - изменить.

но ключ в любом случае вам понадобится по причинам:

1. скорость при наличии ключа значительно увеличивается.

2. решение homm - единственно правильное