powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Вродебы не стоит заморачиваться, но лучше спрошу!
10 сообщений из 10, страница 1 из 1
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043478
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет всем!
И конечно всех с НОВЫМ ГОДОМ! Желаю всем успехов, счастья и здоровья в новом году!

А теперь к делу, так сказать к работе... Как говорят встретишь новый год, так его и проведёшь, я стараюсь работать!

Вопрос такой, я тут создаю систему, которая предназначена для распространения. Систему буду распростаранять с исходными кодами и с описанием структуры БД, соответственно кто угодно сможет доработать модули к этой системе, создать необходимые таблицы процедуры и т.д.!
Я же непосредственно и дальше буду поддерживать эту систему и буду писать обновления.
В системе будут таблицы, представления, хранимые процедуры, функции которые будут создаваться при установке системы, и тоже самое будет создаваться пользователями при работе с системой через модули системы. Ну например при установке будет создаваться таблица пользователей, прав, ролей и т.д. А при работе с системой через модули будут создаваться таблицы контрагентов, справочников и т.д.!
Суть вопроса такова, чтобы было проще понимать и разделять, я планирую создавать их в разных схемах.
Вот только название схем я придумать не могу, но есть несколько вариантов. Для таблиц созданных при установке/обновлении системы будут создаваться в схеме с именем SYS(системная) или STD(стандартная), а таблицы созданные пользователями при работе системы будут создаваться в схеме либо USR(пользовательские) или EXT(расширенные). Вот есть такие варианты. Если есть у кого другие варианты, то сообщите или выберите из этого!
ТАблицы которые будут создаваться другими пользователями не через стандартные модули будут создаваться в третьих схемах, чтобы при обновлении системы не пересекались имена таблиц! Спасибо большое.
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043482
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не знаю, на чем Вы собираетесь писать (СКЛ или орацл), но и там и там -
SYS лучше не трогать.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043500
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky
Не знаю, на чем Вы собираетесь писать (СКЛ или орацл), но и там и там -
SYS лучше не трогать.
Posted via ActualForum NNTP Server 1.4


Да, согласен, некоторых к томуже будет вводить в заблуждение! Может есть ещё вариант или STD?
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043757
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На мой вкус маловато сокращений для классификации признаков сущностей.

Системные справочники
Стандартные справочники с общими понятиями
Специализированные справочники предметной области, редко меняющиеся или не меняющиеся
Часто меняемые пользователем справочники предметной области
"Обычные" таблицы данных предметной области
Таблицы данных, реализующих отношения многие-ко-многим предметной области
"Исторические" таблицы данных предметной области
Насчитанные денормализованные таблицы - суммарные, сводные, другие агрегаты и т.п. предметной области

"Системные" таблицы, отвечающие за экспорт-импорт, генерацию документов, аудит пользователей, метаданные, и прочая и прочая ...
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043801
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> чтобы было проще понимать и разделять, я планирую создавать их в разных схемах

Нормальное желание. Но на Вашем месте я бы не использовал схемы. Сразу увеличится количество СУБД для Вашего пакета.

Что и на чем собираетесь писать, если не секрет?
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043813
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> чтобы было проще понимать и разделять, я планирую создавать их в разных схемах

Нормальное желание. Но на Вашем месте я бы не использовал схемы. Сразу увеличится количество СУБД для Вашего пакета.

Что и на чем собираетесь писать, если не секрет?

Я не понимаю, как увеличится количество СУБД? И что под этим имеется в виду?

Собираюсь писать на MS Visual Studio 2008, а сервер PostgreSQL!

В последнее время жёстко с лицензией становится, вот я думаю PostgreSQL даст некоторую популярность продукту в том что он свободный и что ставится на Linux! Да и клиентскую часть тоже сделаю чтобы под Linux тоже можно было использовать!
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043820
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я не понимаю, как увеличится количество СУБД?

Не все СУБД поддерживают схемы. Отказываясь от использования схем, Вы имеете потенциальную возможность использовать другие СУБД с незначительными изменениями кода.

> Собираюсь писать на MS Visual Studio 2008, а сервер PostgreSQL!

Изначально дохлый вариант. Напрасно тратите время.
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043839
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Схемы сейчас поддерживаются почти во всех современных БД.
guest_20040621Изначально дохлый вариант. Напрасно тратите время.

И почему это дохлый вариант? Конечно это не MS SQL 2005, но работать должно нормально!
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35043939
Paul Sacks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Думаю, что вам лучше всего подойдет FireBird. Информация здесь: http://ibase.ru
...
Рейтинг: 0 / 0
Вродебы не стоит заморачиваться, но лучше спрошу!
    #35044428
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Paul SacksДумаю, что вам лучше всего подойдет FireBird. Информация здесь: http://]ibase.ru

И почему вы думаете что он мне больше подойдёт, какие есть основания?

И если можно то хотелосьбы услышать ответ по теме!
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Вродебы не стоит заморачиваться, но лучше спрошу!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]