Me parece que "Software security assurance" es un término/concepto relativamente nuevo, personalmente no lo he visto traducido en algún lado. Si me atreviera a darle una traducción a las partes donde aparece yo diría:


ASVS Level 1 is for low assurance levels
El nivel 1 de ASVS es para niveles bajos de aseguramiento

it is not effective assurance and must stop
no implica un aseguramiento efectivo y debería dejar de realizarse

We strongly encourage the use of a wide range of security assurance and verification
Animamos encarecidamente a usar un amplio rango de [técnicas de] aseguramiento y verificación

Level 3 - High value, high assurance, or high safety
Nivel 3 - De alto valor, con garantías elevadas o de alta seguridad


Tal vez el principal problema es que se usa en combinación 2 palabras que pueden ser "seguridad" (garantía y protección), pero en español "seguridad de la seguridad" no suena nada bien y es ambigüo. Yo me inclino por "aseguramiento" para "security assurance", o tal vez dejar el término sin traducir. La idea general es un estándar para asegurar (garantizar) la seguridad (nivel de protección) de un sistema.

Se me ocurrió esto en PostgreSQL, supongo que también funcionará en Oracle:

SELECT prueba.*
FROM prueba
INNER JOIN (SELECT n, MIN(fecha) fecha FROM prueba GROUP BY n) temp ON prueba.n = temp.n
WHERE prueba.cod = 1
ORDER BY temp.fecha;

Aprender a usar SQLite con Android Studio puede ser algo abrumador al principio por la manera en que Android recomienda acceder a las bases de datos.

Te recomiendo que vayas leyendo sobre la capa de abstracción Room:

https://developer.android.com/training/data-storage/room/index.html

Es como un overkill solo para leer y actualizar, pero te servirá comenzar por esto cuando tengas que hacer un proyecto más grande.

Efectivamente la mejor forma es usando una base de datos, pero el método efectivo para hacerlo digamos que no hay uno solo, deberás buscar y decidir por ti mismo cual se adapta mejor a tu situación. Como lo has mencionado, ya que muchos hacen lo mismo generalmente lo mejor es no volver a inventar la rueda y usar un CMS que te dé lo que necesites. Pero para empezar una estructura simple de base de datos como la que mencionas te puede servir muy bien. Luego vas agregando más cosas según necesites: por ejemplo, una tabla de autores.

Edit: Si quieres tener una idea más completa, podrías descargar el fuente de algún CMS que ya haga esto (por ejemplo, Wordpress) y darle un vistazo a la estructura de la base de datos que utiliza. Claro que la estructura que verás será algo compleja por toda la funcionalidad que se le ha ido agregando a cada CMS.

¿Me podrías explicar primero por qué quieres hacer esto? Específicamente ¿Por qué tienes datos duplicados en tu base de datos? Yo diría que lo mejor sería tener una tabla digamos:

tabla1:

id -> int(11) -> autoincrement
userid -> int(11) FK tabla2(userid)

tabla2:
userid -> int(11)
nombre -> varchar(20)
direccion -> varchar(20)

Eso asumiendo que tu tabla1 va a crecer con otros datos y tienes tus razones de tener esos datos en tablas separadas. Añadiendo la Foreign Key ya tienes una referencia que relacionará tu id de una tabla con los datos del mismo userid en la otra tabla, pero no sé cómo manejará esto phpmyadmin, pero al menos desde consultas ya puedes obtener ambos datos haciendo un JOIN.

¿Entonces quieres que te hagamos la tarea?

Espero haber entendido bien:

postgres=# SELECT DISTINCT ON (id) * FROM test WHERE tipo = 'b' ORDER BY id, linea;
 id | tipo | linea | nombre 
----+------+-------+--------
  2 | b    |     1 | pepe
(1 ROW)

No me gusta eso de que estás concatenando el parámetro a la consulta, no es una buena práctica. Más bien mira como hacer consultas parametrizadas en VB.net. Esto puede o no estar relacionado con tu problema, pero siempre es una buena idea ir haciéndolo bien desde el principio.

Por otro lado, ¿Access tiene tipo de dato Fecha? Puede estar ocurriendo un comportamiento inesperado por estar pasando el parámetro como un string.

Un SELECT INTO sirve para guardar lo que retorne el SELECT en una variable para su uso posterior, en este caso en "id_departamento".

Me parece que para este ejercicio se hace primero un SELECT INTO para el manejo de la excepción "no_data_found". Si haces el UPDATE directo y resulta que no existe el id del departamento, el UPDATE no tiene por qué fallar, más bien concluye con éxito pero no actualiza ningún registro. Sin embargo un SELECT INTO lanzará un error cuando no haya resultados, así puedes asegurarte de mandar el mensaje correcto.

En efecto, no se limita a Intel.

Ah y son 2: Meltdown y Spectre. Aquí hay buena info (en inglés) al respecto: https://spectreattack.com/

Lo peor es que no hay forma sencilla de evitar el bug: o esperas un nuevo procesador ($$$) que no venga con la falla, o parchas el SO con su respectivo bajón en el rendimiento.