and_y87

Форум программистов и сисадминов Киберфорум

Войти

Регистрация
Восстановить пароль

Словари

Запись от and_y87 размещена 10.04.2024 в 23:54

Показов 1772 Комментарии 4

Метки mysql, postgres, postgresql, база данных, базы данных

Хочется, что бы работа шла быстро и без ошибок. Особенно без грамматических во всякого рода запросах.

Заказчик дал задачу: "Сделать множество списков, которые он смог бы расширять".

На этапе проектирования приложения сделали таблицы в базе данных:

dictionary - словари/справочники
dictionary_option - значения для справочника: элементы option, выпадающего списка
dictionary_value - список привязки значений(dictionary_option) к моделям для множественного выбора

всё "работает как швейцарские часы"... но мысль гложет меня:

А может надо было обозвать таблицы без приставки?

dictionary
option
value

Что бы нативный SQL был короче:

SQL
1
2
3
4
SELECT u.*, o.value AS 'office'
  FROM USER u
    LEFT JOIN `option` o ON o.id = u.offile_id
  WHERE id = 2

SQL
1
2
3
4
SELECT u.*, `do`.value AS 'office'
  FROM USER u
    LEFT JOIN dictionary_option `do` ON `do`.id = u.offile_id
  WHERE id = 2

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

Пока писал, поразмыслил... и буду плакать - стоят они своих имён...

С одной стороны - минус такой:

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

С одной стороны - удобно:

таблицы находятся рядом друг с другом
и самое важное - имя таблицы является очень чётким и ясным

P.S. в нашем случае dictionary_value не даёт столь очевидный посыл что она содержит, и её бы переименовать, но что имеем то имеем

option и value кратко, лаконично, но как кратко так же и неясно:
что это за значение и что это за опции... разработчик помнить связь с таблицей dictionary будет дня 2-3...
далее эти таблицы будут вызывать вопросы... и уйдёт время на понимание что это и зачем это...

Метки mysql, postgres, postgresql, база данных, базы данных

Размещено в MySQL, Back-End Разработка, Разработка Сайтов

« Yii2 REST API params Главная страница если в Yii2 у пагинации слетает стиль »

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.

Всего комментариев 4

Комментарии

На мой взгляд лучше с приставками. И дело тут больше не в "понмю/не помню". Проект будет расти и могут появится еще какие то таблицы где хочется назвать "value". А потом еще друг поделится готовым модулем с другого проекта. Т.е., строго говоря, может вообще еще подумать еще и добавлении даже префикса обозначающего вендора. Иными словами подход аналогичен наименованию классов.

Что касается про "забыл" если я правильно понял предыдущую запись вы пользуетесь yii, и вероятно у вас дам доктрина. Потом как разработчик вы в первую очередь оперируете сущностями, а не тем как они в БД размещаются. Нужно ли вам часто в базу лезть? Ведь однажды вы может изобретете (ну или воспользуетесь созданной кем то) какую то систему хранения крутую где вообще нет ни столбцов ни таблицы

Запись от voral размещена 11.04.2024 в 06:59 voral вне форума

Сообщение от voral

На мой взгляд лучше с приставками

лучше взять нормальную ОРСУБД, например, PostgreSQL

Запись от XLAT размещена 11.04.2024 в 09:27 XLAT вне форума

Сообщение от voral

Согласен

Сообщение от voral

Что касается про "забыл" если я правильно понял предыдущую запись вы пользуетесь yii)

Верно

Сообщение от voral

и вероятно у вас дам доктрина

доктрины нет.

Сообщение от voral

Потом как разработчик вы в первую очередь оперируете сущностями, а не тем как они в БД размещаются.)

Полностью согласен.

Сообщение от voral

Нужно ли вам часто в базу лезть?

Как писал: "мы живём в сложном мире". Увы но очень часто... Гораздо чаще чем хотелось бы...
Заказчик периодически, на что то указывает через свои домыслы и из БД достаю данные показывая факты вместо досмыслов.
И все эти домыслы очень специфичны

Сообщение от voral

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

Это да... тоже согласен с посылом.

Запись от and_y87 размещена 12.05.2024 в 12:57 and_y87 вне форума

Сообщение от XLAT

лучше взять нормальную ОРСУБД, например, PostgreSQL

о! мы как раз её используем.

Но мысль в посте была про другое...

Запись от and_y87 размещена 12.05.2024 в 12:58 and_y87 вне форума

and_y87

Регистрация 27.02.2012
Адрес Россия, Москва, САО
Сообщений 1,379
Записей в блоге 98

Новые блоги и статьи Все статьи Все блоги /
Модель здравосохранения 17. Планы на выгорание anaschu 23.05.2026 Вот конкретная схема реализации: В классе Работник добавить: накопленнаяУсталость — растёт каждый час работы, снижается в перерывы и болезни коэффициентПрезентеизма — снижает продуктивность. . .	Изменение цветов в палитре gif файла aka фавикона russiannick 23.05.2026 Изменение цветов в палитре gif файла, юзаемого как фавиконка в составе html-файла, помещенная в base64, средствами нативного Java Script, навеянное сном в майский день. Для работы необходим браузер,. . .	Модель здравосохранения 16. Слишком хорошие и здоровые сотрудники уходят, недовольные зарплатой anaschu 23.05.2026 Отладка увольнений и настройка производительности Сегодня во второй половине дня разобрались с механикой увольнений и настроили коэффициент сложности заданий. Вот что было сделано. . . .	Как я стал коммунистом))) Модель сохранения здоровья сотрудников, запись блога номер 15 anaschu 23.05.2026 Внезапно хорошее здоровье сотрудников не нужно капиталистам?))
Модель здравоСохранения 15. Как мы чинили AnyLogic модель рабочего коллектива: сочленение диаграммы состояний болезней и поломок в ресурспул anaschu 23.05.2026 Как мы чинили AnyLogic модель рабочего коллектива Сегодня разобрались с пятью багами, из-за которых модель либо падала с ошибкой, либо давала совершенно бессмысленные результаты. Каждый баг был. . .	Диалоги с ИИ zorxor 23.05.2026 Насколько я понимаю - Вы - Искусственный Интеллект. Это так? Да, всё верно. Я — искусственный интеллект. Я представляю собой большую языковую модель, созданную для помощи в самых разных задачах. . . .	Модель здравосохранения 14. Собираем всю модель вместе. anaschu 22.05.2026 Модель собрана. В будущих постах на видео я покажу, как она работает. В этом посте запускаем её, проверяем результаты и разбираем что можно с ней делать дальше. Перед запуском проверяем. . .	Модель здравоохранения 13. Добавление самой системы здравоохранения. anaschu 22.05.2026 В предыдущем посте мы настроили болезни. Теперь добавим события, которые управляют здоровьем всего коллектива, а также настроим рабочий график и расчёт финансов. В Main создаём четыре события. . . .

Наверх

Сообщение форума

Отменить изменения