Решил тут базу не на бумажке нарисовать, а в какой-нибудь программулинке. Да что-то как-то не осилил. Посоветуйте программку. Ничего кроме визуализации мне не требуется (т.е. строить SQL - не надо, ручками построю) Что нужно - так это чтоб стрелочки рисовались не от табличке к табличке (в рандомное место это таблички), а от ключа к ключу. Т.е. мне именно наглядность нужна. пробовал: erwin, bpwin, casestudio 2, toad data modeller Все они реляции рисуют не так
Фуф, Перебрал ещё 3 программулинки. В итоге нашёл то, что хотел. DB Architect 4.1 от Visual Paradigm До visio так и не добрался. Когда скачалась - уже DBArch нашёл. Спасибо за советы.
РРрр Это был пример, поясняющий что мне хотелось бы видеть. Таблиц-то больше. Я пока даже не знаю сколько. Ещё не все придумал (а следовательно в уме не удержу).
общие рекомендации (мои 5 копеек) в юзерсе связь с кантри не нужна ? только связь с городом, связанным со страной icq лучше хранить в varchar даты в datetime деньги во float или currency (если есть) для денежных операций рекомендуется создать таблицу логов ? кто, когда, что на что менял ? решит много проблем в дальнейшем в офферсе: для многовалютных операций, желательно поле курса валют плюс ссылка на таблицу объектов оплаты (или таблицу объектов оплаты по данному платежу) ? что оплачиваем (кроме самого описания) плюс тип оплаты (нал/безнал/карта/инет-деньги)
Вообще нужна, т.к. я забыл ещё поле добавить - city_other (varchar). (в city конечно же есть country_id, я просто когда тестировал - забыл добавить) Но даже если и нет такого, то всё равно мне удобнее держать некоторую избыточность данных, дабы запросов лишних не плодить. А вот теперь давай по пунктам _Почему лучше_: 1 - ICQ - varchar 2 - даты в datetime (из-за наглядности?) С деньгами - понятно, но у меня тут ограничения заказчика - целые суммы. Угу, логи планирую вести и курс реальных валют к внутренним "кредитам" тоже. А вот про таблицу объектов оплаты - не понял
Тем, что: а) долго; б) руководство - ебланы, 10% моей работы - борьба с руководством, бля; в) есть задачи, которые надо успеть закрыть в краткосрочной перспективе.
нихачу олап, тем паче, оракул какой-нить или ибм. Да и сроки, наверняка, жёсткие. А у меня график боль-менее свободный, занимаюсь всем ? телефония-сисадминство-сайт-sql-прогописательство ? к чему, в данный момент, душа лежит. Да и по з/п уже близко. Но, всё равно спасибо. Лучше, как Бонд посоветовал, воспитать. Я, вот, воспитываю.
Теоритическая ситуация перемещение одного города в другую страну создаст множественный геморрой. На самом деле, это уже привычка ? проще оптимизировать запрос, чем иметь потенциальный геморрой в перспективе. icq ? как только номера перейдут за 10 знаков ? получишь проблемы в int даты ? в int'е что считаешь, количество дней? И как будешь пересчитывать? Зато в БД есть спецполе, хранящее дату и время. деньги ? и как на float-курс умножать будешь? А для многовалютных операций нужно два поля: сумма оплаты в валюте и пересчитанная в нац. валюту сумма. Округлять данные при выводе. Таблица товаров или услуг. Легче отслеживать частичные оплаты, популярность товаров/услуг, резервирование тов/услуг.
Угу, понял. Не, в unix timestmap (с 1970 который) У меня вся логика вне базы лежит. Всё равно не понял Не суть.
а если народ придёт с годом рождения до 70-го? тебе, конечно, виднее. собственно, эти типы полей можно переконвертировать в другие, если будет такая потребность. Прорисуй всю схему в начале (ну, этим ты уже занялся). И изучи все возможные процессы ? доставай заказчика сейчас, потом сложнее будет.
