обучениях?)
такой у меня стериотип что это самая не защищённая бд, кто что скажет?
SQL это не БД это язык запросов
... 1. SQL это язык, а не БД 2. Что такое "защищенная бд"? Почему бд вообще должна быть "защищенной" из коробки? За безопасность отвечают совершенно другие слои приложения 3. Разработчики интерфейсов сидят в чатах верстальщиков и дезигнеров
Реляционные базы данных по прежнему подходят для большинства задач лучше всего.
то изучить как общаеться sql это только плюс, и синтаксис сильно отличаться вряд ли будет верно?
И, что эта выдержка из Википедии должна объяснить?
для опытного скуельщика - наверное зиро поя/прояснений
Знать синтаксис sql в общих чертах конечно нужно, в жизни пригодится. К тому же он простой.
Синтаксис может и простой, а вот уметь строить запросы - непросто)
Давай все таки определим, что ты подразумеваешь под проблемами с безопасностью 1. Ограничение доступа к хранимым данным. СУБД не должна за это отвечать впринципе. 2. Защита от самопроизвольной утери данных. Любая современная СУБД, независимо от того реляционная она или нет, такого не допускает. К in-memory хранилищам это не относится. Защита от утери данных в следствии внешнего воздействия (пожар, наводнение, senior-drop-database-engineer) не относится к зоне ответственности СУБД 3. Специфичные вопросы реализации. К безопасности они не имеют никакого отношения. Реляционная модель сама по себе не идеальна, и отклонения от нее не считаются однозначными минусами. Да, обращение к именованным элементам по индексу это плохая практика независимо от того, где она применяется. Поддержка нулевых значений - необходимый инструмент. Дублирование данных, и отклонение от 4 нормальной формы считается критической проблемой только в университетских лабораторных по базам данных. В реальных проектах денормализация используется регулярно. И ни одна СУБД не сможет защитить проект от альтернативно одаренного разработчика. Это не её зона ответственности.
сможешь написать в лс или добавить напишу?
Обсуждают сегодня